On Thu, Aug 20, 2009 at 13:40, Derek Baum <derek.b...@paremus.com> wrote:
> >> FELIX-1471 proposes using () for grouping and $() for evaluation. > >> So the above example would become: > >> > x = (echo aa; (echo ab; echo ac | grep -n a | tac)) > >> > > > > Not sure about this one. > > I guess i've been fooled in my testing by the fact that when evaluating a > > command, you have two results: the output on the console and the object > > returned by the command. > > We need to handle both at some point. > > But for this, we need to exactly define when the returned object will be > > printed to the console (or the piped output stream). > > > > Yes, I raised FELIX-1474 about the implicit writing of command results to > pipes. > We should discuss this separately to avoid complicating this thread. > > > > The next question is what happens when "..." is defined by multiple > tokens: > >> x = a b > > What does that mean ? I'm not sure of the answer. > > It assigns x the result of the command: a b > See Peter's initial comment in this thread: > > >>> a = hello world > >>>Is NOT a = "hello world". And I do not think it should be. > > > > The patch for FELIX-1325 alter this behavior and reject any assignment > with multiple arguments. > > I don't think that this is necessary. RFC-132 explicitly allows this > (4.13 Command calling): > <string> '=' <value> + execute values as statements, set > result as variable > > However, if a single value is used in an assignment, then it shouldn't > be executed, so: > x = echo > does NOT set x to "" (the result of echo). > Isn't that a bit worrying to have the same syntax behaving in different ways depending on the number of arguments ? > > > >> FWIW I still think it is possible to solve this without introducing $(), > > > This made me think a bit differently. The real issue is not about > grouping > > / evaluating. > > Currently, the < > operator means: evaluate the command line inside and > > return the value. > > The real problem comes from the fact that the number of evaluations is > > wrong. > > So I came up with a new simplier patch that I think solve the issue while > > keeping <> as you mentionned. > > I've attached it to FELIX-1471 and it's available at > > > https://issues.apache.org/jira/secure/attachment/12417086/FELIX-1471-2.patch > > It also includes a fix for FELIX-1325 and FELIX-1498, and introduce a new > > "eval" keyword. > > > > Let me know what you think, but this looks like a cleaner solution. > > Yes, this is much cleaner. I mentioned the use of an eval function > earlier in this thread. > > I have tested FELIX-1471-2.patch and although mostly OK, e.g. > > ka...@root> <echo a a; <echo a b; echo ac | grep -n a | tac>> > a a > 1 a b 3 ac > > as expected. > > I don't like the new assignment restriction: > > ka...@root> x = <echo a a; <echo a b; echo ac | grep -n a | tac>> > a a > pipe: java.lang.IllegalArgumentException: Assignements can only have a > single argument > > > ka...@root> x = <echo hello world> > hello world > ka...@root> echo $x > null > > ensure we are using osgi:echo (which returns a String): > ka...@root> SCOPE=osgi:* > osgi:* > > ka...@root> x = <echo hello world> > pipe: java.lang.IllegalArgumentException: Assignements can only have a > single > agument > > ka...@root> x = '<echo hello world>' > hello world > > > I have further simplified FELIX-1471-2.patch and created FELIX-1471-3.patch > > https://issues.apache.org/jira/secure/attachment/12417131/FELIX-1471-3.patch > > 1. removes restriction that assignments only have single argument > 2. removes code to re-parse string results - not needed now we have eval() > (eval is now a regular command like tac, rather than a special > keyword). For re-parsing the results, i think this is an important feature, regardless of eval() If we don't reparse the arguments, then > a = "echo b"; eval $a would throw an unknown command exception "echo b" as "echo b" would be considered a single argument. I think in this case, we should have > $a b > eval $a b If you don't want this behavior, you can enclose $a in double quotes. 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 * all parameters are converted to strings, which i think is not what is expected. I much rather the previous behavior and keep eval as a keyword instead. > > 3. updated tests > > Let me know if this works for you. > > Derek > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
