On Saturday 18 February 2006 10:51 am, Ralf Wildenhues wrote: > * Keith Marshall wrote on Sat, Feb 18, 2006 at 11:26:30AM CET: > > On Friday 17 February 2006 1:12 pm, Ralf Wildenhues wrote: > > > > pwd_curdir="`$1`" > > > > pwd_srcdir="`cd $srcdir && $1`" > > > > > > The double quotes are not necessary here. > > > > Not just unnecessary, but positively harmful. Several shells will > > fail to parse this correctly, *including* the MSYS version of bash. > > 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" > ... and I believe there are places in autotools that rely > on this. Seems we need to work around them by using variable > assignments as intermediates. > > 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. > 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. > 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). Regards, Keith. _______________________________________________ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
