2009/8/17 Guillaume Nodet <gno...@gmail.com>
>
> So in short, the patch does the following:
> * replace <> with $()
> * use ( ) for grouping commands when on the edge of the command
> * make the number of evaluation predictable
> * have a syntax and semantic which is mostly (fully) in sync with bash
> * re-evaluate / split expanded arguments that are not quoted
I can still see no reason for having () and $() as two separate operators.
This unncessarily compllicates syntax without adding any new capability.
You previously gave the following example to demonstrate the need for a
separate grouping operator:
>The grouping operator is imho needed to be able to order pipes and columns:
> (echo a ; echo b) | tac
> echo a ; (echo b | tac)
However, this example works fine with the existing <> execution quotes:
ka...@root> <echo a; echo b> | tac
ab
ka...@root> echo a; <echo b | tac>
a
b
Do you have any other example or use case that demonstrates the need for a
separate grouping operator?
() in bash is NOT only used for grouping - it executes the command within
(), just like the existing <>.
$() in bash executes and captures stdout into a string - equivalent to
<command args | tac> in gogo.
To try to understand the need for separate () and $() operators, I have
taken the gogo TestParser.java from the FELIX-1471.patch and replaced both
$() and () with <>. I then ran the test against the unpatched code.
All tests worked except some newly added tests within
testGroupingAndEvaluation() like:
assertEquals("a", c.execute("<echo echo a>") + "");
This fails because <echo echo a> evaluates to the String "echo a", which is
then evaluated as a command and the command 'echo a' is not found.
assertEquals("a", c.execute("$(echo echo a)") + "");
This works because of the complex re-parsing done by $() that you describe
below.
In bash, if you need to re-parse some text, you use the 'eval' command:
$ eval $(echo echo '$HOME')
/Users/derek
We could take exactly the same approach in gogo, by adding a simple eval
command for use on the rare occassions when it is required.
Derek
>
>
> I'm happy to discuss things further, but the major problem is related to
> make the evaluation predictable, which sounds easy, but is not really ...
> And this require to re-evaluate / split the expanded arguments.
> See the following example:
> assertEquals("a", c.execute("$($(echo echo echo a)) | capture"));
> The "echo echo echo a" command is executed and prints "echo echo a". This
> result is inside $() so it has to be interpreted as a full command line,
> not
> as a single argument which would be a string "echo echo a" as this would
> return a command not found.
>
>
