Re: ensure a VPATH build

[Ralf Wildenhues]

* 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