libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HEAD: func_show_eval shell expansion issue


From: Noah Misch
Subject: Re: HEAD: func_show_eval shell expansion issue
Date: Thu, 25 Aug 2005 18:46:51 -0700
User-agent: Mutt/1.5.6i

On Thu, Aug 25, 2005 at 04:54:06PM +0200, Ralf Wildenhues wrote:
> * 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?

It improves output for code like this:

flags='-Wl,bad"char'
foo_commands="gcc \$flags -c 'foo\$bar.c'"
func_show_eval "$foo_commands"

If you simply echo the commands, you see `gcc $flags -c foo$bar.c'.  With a
robust func_quote_for_expand implementation, you see `gcc -Wl,bad"char -c
foo$bar.c', which is more descriptive.

I do not know how many func_show_eval call sites `eval' strings bearing
parameter expansions, and thereby benefit from this.

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

Yes; that `eval' looks shaky.

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

This is syntactically invalid if $allow_undefined_flag, is, say, `foo"bar'.  It
silently does the wrong thing on `-Wl,'strange$flag''.  func_quote_for_expand
aims to handle cases like those.

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

Yes, I bet the double eval is wrong.  No, I think someone could make a `sed'
script that still does the right thing.  Not me, though.

Note that only a handful of call sites have the double eval.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]