Re: Completion list showed twice using show-all-if-ambiguous and menu-complete together
On Friday, April 5, 2013 9:59:11 PM UTC+2, Chet Ramey wrote: On 4/4/13 7:53 AM, reha...@gmail.com wrote: Hi, Ubuntu 12.10, Bash 4.2.37 With the following inputrc ([Ctrl-RightArrow] mapped to menu-complete): set show-all-if-ambiguous on \e[1;5C: menu-complete Actual Behaviour # Type 'ls d' $ ls d # Press tab key $ ls d desktop/ document/ dropbox/ $ ls d # Press [Ctrl-RightArrow] $ ls d desktop/ document/ dropbox/ $ ls d desktop/ document/ dropbox/ $ ls desktop/ Desired Behaviour (differs only with last keypress only) # Press [Ctrl-RightArrow] $ ls d desktop/ document/ dropbox/ $ ls desktop/ This is how bash-4.3 will work: the list of possible completions is displayed, then the first from the list is inserted without any intervening keystrokes required. The display will look pretty much like your desired behavior with only one keypress required. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ Hi, Thanks for the answer. However I can already achieve the behaviour you describe by adding the following to my previously described inputrc: TAB: menu-complete I would like not to have to do that - I like the way that with my current inputrc binding as listed in my first post, completion just stops at the common prefix when I hit tab. So with the same directory listing in the example above I can do the following: # Type 'ls d' $ls d desktop/ document/ dropbox/ $ ls d # Type 'o', then press TAB $ ls d desktop/ document/ dropbox/ $ ls document/ I would like the choice between the completion mechanism I used in my first post (manually cycling through completion options), and the completion mechanism in this post (typing extra characters onto the common prefix and then completing again). In any case, the behaviour I described in my first post still seems like a bug. I don't see why, under any circumstances, it make sense for bash to display the same completion list twice. Many thanks, Rehan
Interpretation of escapes in expansions in pattern matching contexts
I couldn't find anything obvious in POSIX that implies which interpretation is correct. Assuming it's unspecified. Bash (4.2.45) uniquely does interpret such escapes for [[, which makes me think this test should say no: x=\\x; if [[ x == $x ]]; then echo yes; else echo no; fi bash: yes ksh: no mksh: no zsh: no However, ksh93 (AJM 93v- 2013-03-17) is unique in that it flips the result depending on [[ ]] or case..esac (bug?), but otherwise it looks like a fairly random spread: x=\\x; case x in $x) echo yes;; *) echo no; esac bash: yes ksh: yes mksh: no posh: no zsh: no dash: yes bb: no jsh: no 18:42:44 jilles: ormaaj, I'm not sure if that's actually a bug 18:43:15 ormaaj: dunno. Bash seems unique in that respect 18:43:23 jilles: you're asking the shell to check if the string x matches the pattern stored in the variable x 19:32:51 jilles: freebsd sh and kmk_ash say no, dash says yes 19:33:40 jilles: Bourne shell says no -- Dan Douglas
Re: Interpretation of escapes in expansions in pattern matching contexts
On 04/06/2013 02:48 AM, Dan Douglas wrote: I couldn't find anything obvious in POSIX that implies which interpretation is correct. Assuming it's unspecified. Correct - POSIX does not specify [[ at all, so any behavior inside [[ is unspecified. However, ksh93 (AJM 93v- 2013-03-17) is unique in that it flips the result depending on [[ ]] or case..esac (bug?), but otherwise it looks like a fairly random spread: x=\\x; case x in $x) echo yes;; *) echo no; esac bash: yes The behavior inside case is specified by POSIX, and bash is correct in returning 'yes'. POSIX requires that each case pattern undergoes parameter expansion, and then the result of that expansion ('\x') is compared against the expansion of word ('x') according to pattern matching rules; http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13. Thos rules state that any character in the pattern that is quoted (which \x is) matches itself, and 'x' matches 'x'. ksh: yes correct mksh: no bug posh: no bug zsh: no bug dash: yes bb: no jsh: no I haven't heard of these two, but they are also bugs. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Interpretation of escapes in expansions in pattern matching contexts
On 2013-04-06 07:01, Eric Blake wrote: bb: no jsh: no I haven't heard of these two, but they are also bugs. I assume bb is busybox ash. Chris pgppwY6f9jNaE.pgp Description: PGP signature
Re: Interpretation of escapes in expansions in pattern matching contexts
On Saturday, April 06, 2013 09:24:52 PM Chris Down wrote: On 2013-04-06 07:01, Eric Blake wrote: bb: no jsh: no I haven't heard of these two, but they are also bugs. I assume bb is busybox ash. Chris It's typically a symlink to busybox yes, which calls the shell. jsh is the default binary name produced by the heirloom build, though I've seen other names used. -- Dan Douglas
Re: Completion list showed twice using show-all-if-ambiguous and menu-complete together
On 4/5/13 5:19 PM, reha...@gmail.com wrote: I would like the choice between the completion mechanism I used in my first post (manually cycling through completion options), and the completion mechanism in this post (typing extra characters onto the common prefix and then completing again). In any case, the behaviour I described in my first post still seems like a bug. I don't see why, under any circumstances, it make sense for bash to display the same completion list twice. OK, I see. Regular tab completion and menu completion don't share state. Menu completion uses some of the completion internals, but is separate from TAB completion. I don't see this changing any time soon. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Interpretation of escapes in expansions in pattern matching contexts
On 4/6/13 4:48 AM, Dan Douglas wrote: I couldn't find anything obvious in POSIX that implies which interpretation is correct. Assuming it's unspecified. Bash (4.2.45) uniquely does interpret such escapes for [[, which makes me think this test should say no: x=\\x; if [[ x == $x ]]; then echo yes; else echo no; fi bash: yes ksh: no mksh: no zsh: no However, ksh93 (AJM 93v- 2013-03-17) is unique in that it flips the result depending on [[ ]] or case..esac (bug?), but otherwise it looks like a fairly random spread: x=\\x; case x in $x) echo yes;; *) echo no; esac These two cases should not be different. They undergo the same expansions, except that the conditional command adds quote removal, which doesn't matter in this case. In both cases, you ask the pattern matching code whether or not the string `x' matches the pattern `\x'. You invoke the same pattern matching code on the same patterns, why would you not get the same answer? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: completion of '../' with symlink component in CWD path
On 3/30/13 5:06 AM, Marcel (Felix) Giannelia wrote: Yeah, discovered set -o physical just after posting, and am considering adopting it... but on the other hand, I'm not so sure the facade behaviour has to be all that elaborate. For instance, if I give you the paths '/path/to/directory' and '..' and tell you to append them, you don't need to know anything special to come up with '/path/to'. I think I'd be OK with a always do path arithmetic mode which behaves consistently like that, or a physical mode. Things being a mish-mash of aspects of both, though, does seem like a bug -- I can't think of a conceptual reason why would, by design, behave differently from tab completion, especially since you can tab-complete its destination. i.e. if you start typing something like cat ../foTab and it helpfully completes to cat ../foo ...then that really should work when you press the return key. Maybe tab completion should only obey the current physical or logical mode setting if it can detect it's being invoked to complete an argument to `cd'. After all, that's the only thing that uses it. It's certainly caused confusion when completing arguments to ls, for instance. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Interpretation of escapes in expansions in pattern matching contexts
On Sat, 6 Apr 2013, Chet Ramey wrote: On 4/6/13 4:48 AM, Dan Douglas wrote: I couldn't find anything obvious in POSIX that implies which interpretation is correct. Assuming it's unspecified. Bash (4.2.45) uniquely does interpret such escapes for [[, which makes me think this test should say no: x=\\x; if [[ x == $x ]]; then echo yes; else echo no; fi bash: yes ksh: no mksh: no zsh: no However, ksh93 (AJM 93v- 2013-03-17) is unique in that it flips the result depending on [[ ]] or case..esac (bug?), but otherwise it looks like a fairly random spread: x=\\x; case x in $x) echo yes;; *) echo no; esac These two cases should not be different. They undergo the same expansions, except that the conditional command adds quote removal, which doesn't matter in this case. In both cases, you ask the pattern matching code whether or not the string `x' matches the pattern `\x'. You invoke the same pattern matching code on the same patterns, why would you not get the same answer? In bash, the expansion differs when in [[ ... ]]: $ x=\\x; if [[ x == $x ]]; then echo yes; else echo no; fi yes $ x=\\x; if [ x == $x ]; then echo yes; else echo no; fi no But not in ksh93: $ x=\\x; if [[ x == $x ]]; then echo yes; else echo no; fi no $ x=\\x; if [ x == $x ]; then echo yes; else echo no; fi no -- Chris F.A. Johnson, http://cfajohnson.com/ Author: Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: Interpretation of escapes in expansions in pattern matching contexts
On 4/6/13 9:59 PM, Chris F.A. Johnson wrote: In bash, the expansion differs when in [[ ... ]]: $ x=\\x; if [[ x == $x ]]; then echo yes; else echo no; fi yes $ x=\\x; if [ x == $x ]; then echo yes; else echo no; fi no OK. The [[ conditional command does pattern matching. The [ (test) command does string comparison. $x expands to `\x' in both cases. But not in ksh93: I'm going to assume ksh93 dequotes the variable. I don't know why. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Interpretation of escapes in expansions in pattern matching contexts
On Saturday, April 06, 2013 09:37:44 PM Chet Ramey wrote: On 4/6/13 4:48 AM, Dan Douglas wrote: I couldn't find anything obvious in POSIX that implies which interpretation is correct. Assuming it's unspecified. Bash (4.2.45) uniquely does interpret such escapes for [[, which makes me think this test should say no: x=\\x; if [[ x == $x ]]; then echo yes; else echo no; fi bash: yes ksh: no mksh: no zsh: no However, ksh93 (AJM 93v- 2013-03-17) is unique in that it flips the result depending on [[ ]] or case..esac (bug?), but otherwise it looks like a fairly random spread: x=\\x; case x in $x) echo yes;; *) echo no; esac These two cases should not be different. They undergo the same expansions, except that the conditional command adds quote removal, which doesn't matter in this case. In both cases, you ask the pattern matching code whether or not the string `x' matches the pattern `\x'. You invoke the same pattern matching code on the same patterns, why would you not get the same answer? I expect they should be the same. I just noticed the discrepancy with ksh93 and wondered what gives. The original question I had in mind is: Is the quoting state of any part of a pattern determined lexically prior to expansions, or are any quotes/escapes within parts of pattern words that were generated by unquoted expansions re- interpreted as quotes by the pattern matcher? I had always thought the former, but now it looks to me like all these shells are saying no because they interpret the expanded words for quoting to determine which parts of the pattern should be literal. This appears to even apply to pathname expansion. $ touch '\foo' $ ksh -c 'x=\\f* IFS=; printf %s\\n $x' \foo $ bash -c 'x=\\f* IFS=; printf %s\\n $x' \f* I'm surprised different implementations are all across the board on this. -- Dan Douglas