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.
