On Thu, Aug 20, 2009 at 15:40, Derek Baum <derek.b...@paremus.com> wrote:
> > > I disagree with having eval as a command. The reason is that is has two > sides effects: > > * all parameters are evaluated once more, so that $xxx expansion will be > > done once again, and it could lead to unwanted results > > this is offset by not implicitly evaluating the args - re-evaluation > only occurs when explicitly invoking eval. > > > * all parameters are converted to strings, which i think is not what is > expected. > > I'm not sure this is a problem. The 3.patch eval is like eval in bash, > and can be used to re-evaluate a string as a script. > > Derek > Well, I think this really lead to undesirable effects: > x = <bundle 0> ... > $x toString org.apache.felix.framework [0] > eval $x toString Command not found *:org.apache.felix.framework I think both should be identical. If you want to evaluate the arguments as a fully new command line, you could use quoting > eval "$x toString" But the opposite can't be done. So I still think we should come back to my earlier proposal about making it a real keyword instead of a command. I think this is independant of wether arguments are re-parsed, though they are related. I've also spotted another problem, but this looks like a different problem: > echo "$x" java.lang.Exception: Unable to convert from [org.apache.felix.framework [0]] to java.util.List<java.lang.String>(error converting collection entry) I would have thought it would behave the same as > echo <$x toString> -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
