[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interpretation of escapes in expansions in pattern matching contexts

From: Dan Douglas
Subject: Re: Interpretation of escapes in expansions in pattern matching contexts
Date: Sat, 06 Apr 2013 22:31:08 -0500
User-agent: KMail/4.8.3 (Linux/3.4.6-pf+; KDE/4.8.3; x86_64; ; )

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'
 $ bash -c 'x=\\f* IFS=; printf %s\\n $x'

I'm surprised different implementations are all across the board on this.
Dan Douglas

reply via email to

[Prev in Thread] Current Thread [Next in Thread]