Re: HEAD: func_show_eval shell expansion issue

[Ralf Wildenhues]

* Noah Misch wrote on Thu, Aug 25, 2005 at 03:42:34PM CEST:
> On Thu, Aug 25, 2005 at 08:41:12AM +0200, Ralf Wildenhues wrote:
> 
> > 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.)
> 
> The hope was to expand parameters in the command for the user.

What?  Where should this be necessary?
Not in all the
  cmds=$foobar_cmds
  eval cmds=\"$cmds\"
  ..
  IFS='~'
  func_show_eval "$cmds"
 ..


loops, they aren't.  And in fact, should libtool ever support objects
with dollar signs in their names, they mustn't either (surely this is
post next stable release).

> These threads provide some background:
> http://lists.gnu.org/archive/html/libtool-patches/2004-10/msg00264.html
> http://lists.gnu.org/archive/html/libtool/2004-10/msg00081.html

Well, easy!  The bug is that $allow_undefined_flag needs to be expanded
once, before issuing the command.  But only that flag needs to be
expanded, and not the whole command line!
  eval "allow_undefined_flag=\"$allow_undefined_flag\""

in a strategic place in ltmain (or maybe save the old value, in case it
needs to be reused).  Surely a bit of other code might need to be
changed as well (audited) so that this holds everywhere, and I'm
certainly not proposing to do this before the next stable release.  All
I'm saying is that it would be the _right_ solution.  (And all the
`func_show_eval $RM ..' would likely have to call a different function,
with a higher eval'ness)

The change from using
  $echo "$cmds"
  $run eval "$cmds"
to using func_show_eval should not have changed semantics nor output at
all, IMVHO.

> > *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?
> 
> What do you mean, different levels of expanded-ness?

Just the above.  Having $cmds eval'ed once in the main code *and* once
in func_show_eval is wrong.  You can't find a regex or sed script
that'll undo that and keep you cozy and warm unless you make assumptions
about what the user gives you on the command line.  Not if you allow 
any kinds of fun stuff in $libobjs, e.g., `$' in object file names.

Would you agree with this judgement?

(I want to agree on the larger picture before the decision of what to do
with the issue at hand that brought up this thread.)

Cheers,
Ralf