Re: Despite text in gnu bash manual, quote removal appears to be performed on case pattern

[Stahlman Family]

----- Original Message ----- 
From: "Chet Ramey" <chet.ramey@case.edu>
To: "Stahlman Family" <brettstahlman@comcast.net>
Cc: <bug-bash@gnu.org>; <chet@case.edu>
Sent: Tuesday, December 12, 2006 2:01 PM
Subject: Re: Despite text in gnu bash manual, quote removal appears to be 
performed on case pattern


> Stahlman Family wrote:
> > Mingw (Msys) Bash 2.04.0(1)-release
> > Microsoft Windows XP Home Edition Version 2002 Service Pack 2
> >
> >
> > Perhaps I'm misunderstanding something, but the way I read the manual
> > text on the case command, if anything is printed in the example below,
> > it would be "2", since if the quotes around " foo bar " are not removed
> > in the case pattern, then the first case is testing the string
> > <space>foo<space>bar<space>
> > against
> > <double-quote><space>foo<space>bar<space><double-quote>
>
> Not exactly.  Strict quote removal is not performed.  The behavior of
> quoted characters is as in pattern matching:  quoted characters match
> themselves, even characters are have special meaning in pattern matching.
>
> There is some internal process of turning, for instance, " foo bar "
> into \ \f\o\o\ \b\a\r\ , but that is not the same as quote removal.

Ahhh. Thanks. That's the piece I was missing. As I understand it then, a pattern can be quoted with literal quotes and/or 
backslashes and the output of the pattern pre-processing stage will be a pattern with only backslash-style quoting (a form that is 
understood by the glob pattern matching code). Although it should have been clear to me in retrospect, I did not realize that the 
glob pattern matching engine understood backslash escaping. Of course, if it didn't, the implementation would be much messier, since 
the pattern pre-processing code (or as I thought, the tokenizing code) would need to set flags of some sort while processing 
patterns (either one for the entire pattern if entire pattern is to be treated as a string, or one for each character in the pattern 
otherwise) to tell the pattern matching code to inhibit glob special character recognition in a certain pattern or section of a 
pattern. In fact, it appears that the "flags" are embedded in the pre-processed pattern as backslashes - much more elegant.

Playing with it now, I'm pleased and relieved to see that interpretation of backslashes within a double quoted pattern is consistent 
with that performed for non-pattern double quoted strings; eg, "\*" is not the same as "*".

This has cleared a number of things up for me.

Thanks,
   Brett S.

> That becomes more clear when the pattern to be quoted is "*":  quote
> removal would turn that into * rather than \*, so you would not be able
> to use "*" to match a literal * if quote removal were performed.
>
> Posix is, as usual, more verbose about this than the bash manual page.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>        Live Strong.  No day but today.
> Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/