double-quoted command substitutions (was: ensure a VPATH build)

[Ralf Wildenhues]

Keith Marshall writes:
> 
> From autoconf-2.59

> |and in fact it is even _more_ portable: in the first case of the first
> |attempt, the computation of `top_srcdir' is not portable, since not all
> |shells properly understand `"`..."..."...`"'.  Worse yet, not all
> |shells understand `"`...\"...\"...`"' the same way.  There is just no
> |portable way to use double-quoted strings inside double-quoted
> |back-quoted expressions (pfew!).
> 
> Granted, that's referring primarily to nested double quotes, with 
> backtick substitution,

The bug for which you posted URLs does not deal with nested double
quotes nor was it reported for assignments (but see below).  Of the
shells I use, only pdksh (in Posix mode) has the bug that is mentioned
in the quoted part of the documentation.

> but there is an inference that the two interact in 
> a non-portable manner, which is best avoided.

If we need to rely on inference in order to make good use of the
documentation, then it is not as good as it should be: it should list
explicitly, and detailedly the constructs that do not work, possibly
also why they don't work, and best with shells and systems mentioned on
which they fail, including versions, so that one can decide whether this
is an ancient bug or a recent one.  If we can't analyze bugs well, it
may be useful to advise against a class of expressions; but then, that
_still_ should be done by precisely saying what should not be used, not
by inference from examples alone.  The text given in the current
documentation does not encompass this new bug.

I have tried the MSYS shell now.  I can reproduce the bug mentioned in the
URLs there, but not on Cygwin, neither with bash on any other system I
could find, nor with /bin/sh on FreeBSD 5.4, OpenBSD 3.8, AIX 4.3.3
HP-UX 10.20, IRIX 6.5, Solaris 2.6, Tru64 4.0D.  I don't have access to
older systems.

With the MSYS shell, the bug also happens on the right hand side
of assignments.  The bug only seems to happen if the double-quoted area
extends further.  So, this is ok and does not add a \01 byte in the
output:
  echo "`./test`"
  echo "`./test`"" -lpq"

while this is not ok:
  echo "`./test` -lpq"

If the "other shells" that have this (or a similar) bug work similarly,
the second line would be a nice workaround that would not require to use
intermediate variables.  Luckily most instances in Autoconf and Libtool
use one of the first two expressions, or use the third but are not
sensitive to the extra byte in the output.

So, any chance you could take a look (or give more hints) on which other
systems this may go wrong, and also whether I should file a bug with
bash or whether this is MSYS specific?

BTW, the most similar bug I could find documented was this
http://www.in-ulm.de/~mascheck/bourne/par_here_com.html which is still
clearly distinct and presumably extinct or irrelevant now.

Cheers,
Ralf