2009/7/16 Peter Kriens <peter.kri...@aqute.biz> > > I do agree that we should replace the <> with (). This makes a lot of sense > and there are not that many filters in use anyway. We could now make filters > <> if we want. > > [snip] > > About the priority of | and ; ... I remember thinking long and hard about > this but forgot why I picked this model, it still seems slightly more > powerful because the newline acts as a ';' with a higher priority than the > '|' but I am not opposed to switching the priority.
if we agree to use $() for command execution instead of <> then we can use () for command grouping, and thus the examples below would work the same in Unix or RFC132 shell: echo a; echo b | cat (echo a; echo b) | cat We could also add a converter to coerce a string into an LDAP filter to make up for stealing the (). > I am not sure about throwing an error when a command is not recognized. > Using its value seems sufficient to me and has some advantages. I do not > think this would ever confuse me. It has already confused users on Karaf :-) A 'command not found' error only occurs if you pass an argument to an unknown command, otherwise it silently evaluates to itself. Although this may be apparent to a user at the console, it would be much more difficult to diagnose in a script containing a mis-spelled command. I have attached a simple patch to experiment with this to https://issues.apache.org/jira/browse/FELIX-1325 This patch simply avoids re-evaluating a single argument to an assignment, so x = hello works as before, but when evaluated in a non-assignment context, it fails if a 'hello' command is not found. Variable expansion using ${ab} rather than $ab is still problematic. the ${ab} notation is in common usage: - Unix allows it to delimit the variable name from following text - Many Java programs interpret ${xx} as expansion of system properties It also works in the RFC132 shell, but in this case {ab} defines a closure and the $ evaulates it. If you really wanted to capture the result of executing ab, then <ab> or our proposed $(ab) is the way to go. This would then allow us to interpret ${ab}, according to its comon usage - enhanced variable expansion. We could also usefully add the Unix variable expansion: ${var:-default} Derek > > > Nice to get some discussion going! However, please note that this is an > OSGi RFC. I will update the RFC in the coming weeks and discuss it in CPEG. > I hope to schedule it then for inclusion in an upcoming compendium. > > I'd like to add one more thing. In Blueprint we spent a lot of time on type > conversion and I like very much what we got there. I think it would be a > good idea to use the same type converters, especially because they also > handle generics when available. > > Kind regards, > > Peter Kriens > >