Re: ensure a VPATH build

[Keith Marshall]

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.