On Sun, Aug 16, 2009 at 13:30, Derek Baum <[email protected]> wrote:

> I've applied the FELIX-1471 patch to Karaf and get an exception when using
> assignment with grouping:
>
>
> ka...@root> x = (echo a; echo b)
> org.osgi.framework.InvalidSyntaxException: expected value|substring
>        at org.apache.felix.framework.FilterImpl.<init>(FilterImpl.java:81)
>
> In RFC132 parens () were used to create an LDAP filter - it looks like it's
> still trying to do that in an assignment.
>
>
> Using $() works OK:
>
> ka...@root> x = $(echo a; echo b)
> a
> b
>
> But if () are supposed to be used for grouping, then I shouldn't need to
> use
> $()?
>

What I did is that i based my patch on the way bash work, mostly to try to
understand some edge cases with $().
Most of those are captured in the test named testGroupingAndEvaluation() in
TestParser.

So, ( ) only work for *grouping* commands.  But in the example above, what
you expect is x to be assigned to the value of the execution of "echo a;
echo b".  So this is not really grouping, but more evaluation.  So it sounds
logical to me to use the $( ) construction instead.

In addition, the grouping operator is mostly used to change the priority
between ';' and '|', so the parentheses can really only appear at the edges
of the command.   Also, ( ) does not change the result of the execution, so
that we have:
        assertEquals("echo a", c.execute("echo echo a | capture"));
        assertEquals("echo a", c.execute("(echo echo a) | capture"));
        assertEquals("echo a", c.execute("((echo echo a)) | capture"));
        assertEquals("echo a", c.execute("(((echo echo a))) | capture"));

What you see is the result of the parser not throwing exceptions when
parentheses are not at the edge of the command, so that those parentheses
are not managed.   That's why the ldap filter construction kicks in, and
that's also why the tests using grep and () don't have to change:
        assertEquals("def", c.execute("echo def|grep (d.*)|capture"));

(actually, my patch seems to change those test, but i'll upload a new one
without those modifications, and the test still succeed without any other
changes).

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'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.



>
>
> Is the FELIX-1325 patch dependent on the FELIX-1471 patch?


I think so.  I've created the latest patch attached on top of FELIX-1471.
The previous one was not, but lead to problems and inconsistencies that
FELIX-1471 fixed.


>
>
> I also noticed that shell:echo doesn't print a space between its last two
> arguments:
>
> ka...@root> shell:echo 1 2 3 4 5
> 1 2 3 45
>

Fixed.  Thx for reporting.


>
> Derek
>
>
>
>
>
> 2009/8/16 Guillaume Nodet <[email protected]>
>
> > I've attached 2 patches to FELIX-1471 and FELIX-1325 to fix those issues.
> > Ftr, those are:
> >  * use () for command grouping and $() for evaluation
> >  * throw an exception when a command is not found, even if it has no
> > arguments
> >
> > Feedback welcome.
> >
> > On Wed, Aug 12, 2009 at 21:06, Guillaume Nodet <[email protected]> wrote:
> >
> > > I'll try to come up with a patch for further discussion.
> > > I think the grouping operator (...) will be handled directly by the
> > parser
> > > without surfacing to the closure and pipes interpreters, while the
> $(...)
> > > for evaluation would be handled by those the way <...> currently works.
> > >
> > >
> > > On Wed, Aug 12, 2009 at 15:37, Richard S. Hall <[email protected]
> > >wrote:
> > >
> > >> On 8/12/09 4:00, Guillaume Nodet wrote:
> > >>
> > >>> So I'd rather have ( ... ) for pure grouping and $( ... ) for
> > evaluating
> > >>> as
> > >>> we have in bash.
> > >>>
> > >>>
> > >>>
> > >>
> > >> That seems reasonable to me.
> > >>
> > >> -> richard
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > > ------------------------
> > > Open Source SOA
> > > http://fusesource.com
> > >
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Reply via email to