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
