>> > 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 ?
bash behaves like this - you only have to quote assignments containing
multiple words:
$ x=hello
$ x=hello world
-bash: world: command not found
$ x='hello world'
However, I can also see the argument for making execution explicit, so
if you wanted to assign the result of executing hello, RFC-132 allows:
x = hello world
but I agree it is clearer to be explicit:
x = <hello world>
Note: FELIX-1471-2.patch does NOT currently allow this:
> x = <echo hello world>
java.lang.IllegalArgumentException: Assignements can only have a
single agument
Surely the result of <> should be a single argument?
You now have to quote the <>, which is not intuitive:
> x = "<echo hello world>"
hello world
> 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.
This depends on the implementation of eval.
In FELIX-1471-3.patch, I have removed the implicit re-parsing and
implemented eval as (effectively):
session.execute(args);
eval can then be used to explicitly re-parse as required:
Our two approaches (2.patch and 3.patch) initially seem similar:
2.patch:
> x = "<echo echo a>"
echo a
> eval $x
a
3.patch:
> x = <echo echo a>
echo a
> eval $x
a
However, more complex examples, yield different results:
2.patch:
> eval "echo hello"
java.lang.IllegalArgumentException: Command not found: *:echo hello
> x = "echo a; echo b"
echo a; echo b
> eval $x
a
result should be 'b'?
> prog = 'x = {echo xxx $it}; x hello'
x = org.apache.felix.gogo.runtime.shell.clos...@87e9b2; x hello
> eval $prog
org.apache.felix.gogo.runtime.shell.clos...@87e9b2
3.patch:
> eval "echo hello"
hello
> x = "echo a; echo b"
echo a; echo b
> eval $x
b
> prog = 'x = {echo xxx $it}; x hello'
x = {echo xxx $it}; x hello
> eval $prog
xxx hello
> I think in this case, we should have
>> $a
> b
>> eval $a
> b
2.patch alllows:
> $a
b
while 3.patch requires explicit eval:
> eval $a
b
> $a
java.lang.IllegalArgumentException: Command not found: *:echo b
> 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
