Re: [bug] backslash stripped in sh/ksh emulation

[Peter Stephenson <pws@csr.com>]

Stephane Chazelas <Stephane_Chazelas@yahoo.fr> wrote:
> $ ARGV0=ksh zsh -xc 'a="\\*"; case $a in *\\*) echo a;; esac'
> + a='\*'
> + case * (*\*)
> 
> Can anyone explain it? It's OK if $a is quoted as in <case "$a">
> 
> After investigation, it appears it is triggered by globsubst.

You're basically pointing out that in:

a='\\*'
print -r ${~a}

the output is

\*

with only a single backslash (I'm assuming nonomatch is set and the pattern
doesn't match a file --- everything is OK if it does).  Yes, this does seem
to be a bug: the string shouldn't be altered if it doesn't match a pattern,
and the use is inconsistent with other shells, which is bad here since
glob_subst is partly designed to provide compatibility.

Fixing it isn't that trivial, given the constraints:

- Nothing else should change, i.e. the myriad other points at which
  quoting takes place shouldn't be affected.
- Also, the quoting effect of the first backslash should be retained
  in pattern matching (in other words, ${~a} in the example should match a
  single backslash).
- zsh removes the so-called "null" arguments, essentially the ghosts
  of quoting characters that are only needed to recreate a printed
  representation of the input string, before pattern matching takes
  place, so restoring it after isn't natural in the current code.

The last one is the really tricky one.  Possible a complete rewrite of the
way quoting is handled would make this all work, but I'm not going down
that road.

So I've introduced a variant of Bnull, the ghost of a backslash, called
Bnullkeep.  This is only inserted in the code used for globsubst, isn't
removed by remnulargs(), and is explicitly ignored by pattern matching.  If
the pattern match failed then untokenize() will restore the backslash to
output the original string.

It's possible there are inconsistencies in that there are places that Bnull
and Bnullkeep are treated the same when they should be different, or vice
versa.  It's also possible that there's a point in the code that expects a
tokenized string but hasn't been taught properly about Bnullkeep, since the
pattern matching is the only part I've modified.  However, none of the
existing tests fail, and the new test I've added succeeds.

Nonetheless, this doesn't give me a warm, fuzzy feeling.  If anyone can
think of places where this might have the wrong effect...

I will not be applying this to 4.2.

(It's just possible we could get away with only using Bnullkeep by suitable
changes, simplifying the code a bit.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com