bug-bash
[Top][All Lists]
Advanced

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

Re: Despite text in gnu bash manual, quote removal appears to be perform


From: Stahlman Family
Subject: Re: Despite text in gnu bash manual, quote removal appears to be performed on case pattern
Date: Wed, 13 Dec 2006 06:49:59 -0600


----- Original Message ----- From: "Chet Ramey" <address@hidden>
To: "Stahlman Family" <address@hidden>
Cc: <address@hidden>; <address@hidden>
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    address@hidden    http://cnswww.cns.cwru.edu/~chet/






reply via email to

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