Re: Brace expansion bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/26/12 6:32 AM, Dan Douglas wrote: Hi, hopefully a self-explanatory one today: ~ $ ( set -x -- {a..c}; echo ${*-{1..3}} ) + echo 'a b c' 'a b c' 'a b c' a b c a b c a b c ~ $ ( set -x -- {a..c}; echo ${*/{1..3}/$*} ) + echo 'a b c' 'a b c' 'a b c' a b c a b c a b c I'm told similar glitches have been found before. Looks like this applies to anything that has this sort of replacement context that contains valid brace expansion syntax inside quotes. Brace expansion doesn't actually know very much shell syntax. It's a totally separate part of the word expansion process, and is completely text-based. I sometimes wish there were an expanded tracing mode, one that would display intermediate results after each stage of word expansion. I've implemented it before, but only for debugging. In this case, the first construct expands to ${*-1} ${*-2} ${*-3} which, since the positional parameters are set, expands to three quoted strings, each containing the expansion of $*. Similarly, the second expands to ${*/1/$*} ${*/2/$*} ${*/3/$*} for which the substitution is unsuccessful. Chet - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9x9nsACgkQu1hp8GTqdKsqIQCeNo0NPVoPlQYB1JSpivGxZXd7 3EAAnRdZdsnMbW3GIJEcLnhym5u/2/xc =PQoh -END PGP SIGNATURE-
Brace expansion bug
Hi, hopefully a self-explanatory one today: ~ $ ( set -x -- {a..c}; echo ${*-{1..3}} ) + echo 'a b c' 'a b c' 'a b c' a b c a b c a b c ~ $ ( set -x -- {a..c}; echo ${*/{1..3}/$*} ) + echo 'a b c' 'a b c' 'a b c' a b c a b c a b c I'm told similar glitches have been found before. Looks like this applies to anything that has this sort of replacement context that contains valid brace expansion syntax inside quotes. Bash 4.2.24 - Gentoo amd64 -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: Brace expansion bug
Dan Douglas orm...@gmail.com writes: Hi, hopefully a self-explanatory one today: ~ $ ( set -x -- {a..c}; echo ${*-{1..3}} ) + echo 'a b c' 'a b c' 'a b c' a b c a b c a b c ~ $ ( set -x -- {a..c}; echo ${*/{1..3}/$*} ) + echo 'a b c' 'a b c' 'a b c' a b c a b c a b c *Note (bash) Brace Expansion:: Brace expansion is performed before any other expansions, and any characters special to other expansions are preserved in the result. It is strictly textual. Bash does not apply any syntactic interpretation to the context of the expansion or the text between the braces. To avoid conflicts with parameter expansion, the string `${' is not considered eligible for brace expansion. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Brace expansion bug
On Monday, March 26, 2012 01:44:58 PM you wrote: Dan Douglas orm...@gmail.com writes: Hi, hopefully a self-explanatory one today: ~ $ ( set -x -- {a..c}; echo ${*-{1..3}} ) + echo 'a b c' 'a b c' 'a b c' a b c a b c a b c ~ $ ( set -x -- {a..c}; echo ${*/{1..3}/$*} ) + echo 'a b c' 'a b c' 'a b c' a b c a b c a b c *Note (bash) Brace Expansion:: Brace expansion is performed before any other expansions, and any characters special to other expansions are preserved in the result. It is strictly textual. Bash does not apply any syntactic interpretation to the context of the expansion or the text between the braces. To avoid conflicts with parameter expansion, the string `${' is not considered eligible for brace expansion. Andreas. No other shell I have to test with that has brace expansion behaves this way. Is this intentional? There's a trivial workaround by escaping the first brace, but expansion order shouldn't be relevant here, this is about the parsing and token recognition steps. In order for brace expansion to occur to begin with it would have to first be recognized as such. Ordinarily the inner and outer quotes of the alternate argument expansions are processed separately so that in the case of an unquoted expansion you can have situations like ${x+$y $z} which potentially expands to zero or two words depending on the circumstance. If there's a brace expansion detected, the function of the quotes is modified and the brace expansion becomes stronger from a parsing standpoint. This seems counter-intuitive. Don't know how much I'm allowed to quote here, but a quick read of the POSIX parsing rules and parameter expansion sections suggest to me that the start of the parameter expansion should be the most important factor, and that nested quotes and braces are counted as part of the parameter expansion and escape at least any closing braces (doesn't mention opening brace). They do seem to be emphasizing the point that there's nesting going on and that the shell should try to consider the parameter expansion as a whole first. This is hard to interpret, it was obviously not written to take brace expansion into account. The Bash manpage does specifically omit brace expansion from evaluation of word which I suppose should be a clue that it's intentional. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: Brace expansion bug
On 03/26/2012 07:56 AM, Dan Douglas wrote: Don't know how much I'm allowed to quote here, but a quick read of the POSIX parsing rules and parameter expansion sections suggest to me that the start of the parameter expansion should be the most important factor, and that nested quotes and braces are counted as part of the parameter expansion and escape at least any closing braces (doesn't mention opening brace). POSIX doesn't specify brace expansion. Use of brace expansion is an extension, and since there is no standard, it's hard to say whether it's right or wrong; you can only say whether it behaves as bash documented it to behave. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Brace expansion bug
On Monday, March 26, 2012 08:07:00 AM you wrote: On 03/26/2012 07:56 AM, Dan Douglas wrote: Don't know how much I'm allowed to quote here, but a quick read of the POSIX parsing rules and parameter expansion sections suggest to me that the start of the parameter expansion should be the most important factor, and that nested quotes and braces are counted as part of the parameter expansion and escape at least any closing braces (doesn't mention opening brace). POSIX doesn't specify brace expansion. Use of brace expansion is an extension, and since there is no standard, it's hard to say whether it's right or wrong; you can only say whether it behaves as bash documented it to behave. Fair enough, So long as there's no conflicting language. It is a useful hack if the behavior is intended - slightly betterthan the sometimes tempting but not- so-practical: cmd ${some-expansion}{,} -- Dan Douglas signature.asc Description: This is a digitally signed message part.