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 ks

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 uniq

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.

Re: "typeset +x var" to a variable exported to a function doesn't remove it from the environment.

2013-04-06 Thread Chet Ramey
On 4/5/13 4:50 PM, Chet Ramey wrote: > On 3/25/13 9:37 PM, Dan Douglas wrote: >> Hello, >> >> $ function f { typeset +x x; typeset x=123; echo "$x"; sh -c 'echo >> "$x"'; }; x=abc f >> 123 >> abc >> $ echo "$BASH_VERSION" >> 4.2.45(1)-release >> >> This is inconsistent with a v

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 ==

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' an

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 "n

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 [ (

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