* Keith Marshall wrote on Sat, Feb 18, 2006 at 01:18:07PM CET: > On Saturday 18 February 2006 10:51 am, Ralf Wildenhues wrote: > > > > Ouch. I was referring to the fact that, on the right hand side of > > shell assignments, no word splitting is done. So > > foo=`echo bar baz` > > > > will assign `bar baz' to `foo', not try to execute the command `baz'. > > > > > See: > > > https://sourceforge.net/mailarchive/message.php?msg_id=14306922 > > > https://sourceforge.net/mailarchive/message.php?msg_id=14354463 > > > > This is slightly different, and very bad: the MSYS sh wrongly expands > > backquoted parts inside double-quoted parts. But it is necessary to do > > this sometimes,... > > Where is it *ever* necessary? The backticks themselves serve as quotes. > A string such as > "a string `echo with an embedded backquoted` substring" > > can always be safely rewritten as > "a string "`echo with an embedded backquoted`" substring" No, that is not true. Word splitting is performed after command substitution: $ set "`echo foo bar`"; echo $# 1 $ set `echo foo bar`; echo $# 2 This difference is important. > > Could you confirm that the bug also exists with assignments? > > I'm not sure. I'd never actually encountered the problem with bash, > before this particular MSYS bug report. However, I had previously > encountered it in a groff bug report pertaining to pdfroff, where > backticks withing quotes broke the groff build on several systems, > mostly various flavours of BSD, I think. Could you point me to the bug report? > > Have you filed a bug with bash or is this in a MSYS-specific issue only > > so that the bug should be filed with MSYS? Could you name other shells > > which expose this bug? > > No, I haven't filed a bash, or MSYS specific bug report. The bug is more > prevalent than just bash, so better to avoid it everywhere, than to fix > just one isolate instance. That may well be. I'll file a bug report then, when we have this fully analyzed. > > We should probably add a warning to the Autoconf shell portability > > section. > > Already there! See the node "Shell Substitutions" in autoconf's texinfo > manual. (And given the statement there, the autotools have no excuse for > improper or unsafe usage, IMO). I'm sorry, but please be more precise and quote which part of the node you mean. I cannot find this exact bug described there (CVS Autoconf). What related stuff I can find is this: | ``COMMANDS`' | Posix requires shells to trim all trailing newlines from command | output before substituting it, so assignments like | `dir=`AS_DIRNAME(["$file"])`' will not work as expected if the | directory of `$file' ends in a newline. | | While in general it makes no sense, do not substitute a single | builtin with side effects, because Ash 0.2, trying to optimize, | does not fork a subshell to perform the command. | | For instance, if you wanted to check that `cd' is silent, do not | use `test -z "`cd /`"' because the following can happen: | | $ pwd | /tmp | $ test -z "`cd /`" && pwd | / | | The result of `foo=`exit 1`' is left as an exercise to the reader. But it does not mention your bug; in fact, it mentions that the behavior needs to be different _for assignments_. Please keep in mind that the assignment part is different from the other one. Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
