Re: Completion list showed twice using show-all-if-ambiguous and menu-complete together

2013-04-06 Thread rehanog
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

Interpretation of escapes in expansions in pattern matching contexts

2013-04-06 Thread Dan Douglas
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

Re: Interpretation of escapes in expansions in pattern matching contexts

2013-04-06 Thread Eric Blake
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

Re: Interpretation of escapes in expansions in pattern matching contexts

2013-04-06 Thread Chris Down
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

2013-04-06 Thread Dan Douglas
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

Re: Completion list showed twice using show-all-if-ambiguous and menu-complete together

2013-04-06 Thread Chet Ramey
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).

Re: Interpretation of escapes in expansions in pattern matching contexts

2013-04-06 Thread Chet Ramey
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 ]];

Re: completion of '../' with symlink component in CWD path

2013-04-06 Thread Chet Ramey
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

Re: Interpretation of escapes in expansions in pattern matching contexts

2013-04-06 Thread Chris F.A. Johnson
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

Re: Interpretation of escapes in expansions in pattern matching contexts

2013-04-06 Thread Chet Ramey
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)

Re: Interpretation of escapes in expansions in pattern matching contexts

2013-04-06 Thread Dan Douglas
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