Re: HEAD: func_show_eval shell expansion issue

[Noah Misch]

On Wed, Aug 24, 2005 at 09:51:24PM +0200, Ralf Wildenhues wrote:
> On AIX, when libtool generates a symbol list, it wrongly outputs this:
> 
> | /usr/bin/nm -B -BCpg  .libs/hello.o .libs/foo.o   | awk '{ if (((exit $? == 
> "T") || (exit $? == "D") || (exit $? == "B")) && (substr(,1,1) != ".")) { 
> print  } }' | sort -u > .libs/libhello.exp
                                                          ^
Semi-side note: I wonder how the `3' at the marked location went missing.

> but actually correctly executes this:
> 
> | /usr/bin/nm -B -BCpg  .libs/hello.o .libs/foo.o   | awk '{ if ((($2 == "T") 
> || ($2 == "D") || ($2 == "B")) && (substr(3,1,1) != ".")) { print $3 } }' | 
> sort -u > .libs/libhello.exp

It _looks_ like func_quote_for_expand treats `$2' and `$3' as parameter
expansions and leaves them unescaped.

> Now I'd like to know: which is wrong?
> 
> a) The implementation of func_show_eval

Probably this: actually, func_quote_for_expand, which func_quote_for_eval
calls.  func_quote_for_expand should backslash `$' in its input that the shell
will never treat as starting parameter expansions.  The implementation uses a
simple algorithm that recognizes the `\$foo' as literal, but not `'$foo''.

I wrote a goofy fix for this shortly after Gary and I finalized the current
implementation.  The problem seemed minor, so I did not contribute said goofy
fix at the time.

> b) calling func_show_eval in this situation, where we needed to eval the
> command before?
> 
> This bug is present in HEAD, but not in branch-2-0 nor branch-1-5.
> func_show_eval is used in many situations, are we just using it
> inconsistently now?

This surprises me a lot.  All the relevant functionality is in general.m4sh,
and the diff between HEAD and branch-2-0 does not show anything that would
cause this behavior change.  Perhaps $2 and $3 are empty at this call site in
branch-2-0, but not in HEAD, so the output is still wrong, but the difference
is less obvious?  Would you confirm?

> I actually believe that this a similar issue might cause the troubles
> with the Tru64, too: it does not like unquoted ^ (circumflex), as noted
> here before.  I have audited ltmain and most of libtool.m4 for unquoted
> use and not found any, so I figure the only remaining might be hidden
> inside some eval'ed construction.

Possibly; I think the code gets this right: ^ is one of the characters that
makes func_quote_for_expand double-quote its output.