>> 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).
>> 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).
3. updated tests
Let me know if this works for you.
Derek
