Re: HEAD: func_show_eval shell expansion issue

[Ralf Wildenhues]

Hi Noah,

Thanks for your quick answer!

* Noah Misch wrote on Thu, Aug 25, 2005 at 12:28:35AM CEST:
> 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.

Oops, my mistake, sorry.  See below.

> > 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

I typed this by hand, it should have been substr($3,1,1) of course.
I'm sorry, I tried to be extra careful..

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

I believe so.

> > 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.

Care to contribute it now?

There's one thing I still don't understand: before, we had a bunch of
  $echo "$cmd"
  $run eval "$cmd"

which we now replaced with func_show_eval, which does
func_quote_for_expand only to have yet another eval in the echoing path.

Why not just drop func_quote_for_expand and the extra eval?
(I'm pretty sure I'm overlooking something; it's that I'd like to know
what I am overlooking.)

*time passes* OK, this seems to break a lot of uses of func_show_eval.
But _then_ I see a fundamental problem in the way we use func_show_eval:
We pass it arguments with different levels of expanded-ness.  This is
a subtle problem and needs to be fixed, IMHO.  Am I missing something?

> > 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.

The answer to this is trivial: func_show_eval is defined but not used at
all in branch-2-0 ltmain.m4sh;  func_quote_for_expand is used only once.

> 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?

That makes this question obsolete, right?

> > 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.

Hmm, yes, looks like it.  Darn, I'd hoped I'd find this bugger finally.

Cheers,
Ralf