HEAD: func_show_eval shell expansion issue

[Ralf Wildenhues]

I'm a bit embarassed to note that I _have_ found a bug in HEAD not
present in branch-2-0 (system-independent, BTW):

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

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

The bogus `exit $?' comes from an extra evaluation on the way through to
| func_show_eval "$cmds" 'exit $?'

Now I'd like to know: which is wrong?

a) The implementation of func_show_eval

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?

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.

This is not a system-dependent problem, by the way, I've reproduced it
on GNU/Linux by replacing the export_symbols_cmds setting.

Thanks for any help,
Ralf