In RFC132, although <> are compared to shell backquotes, there are actually just executing the command, and not capturing its output as done by shell backquotes, so I agree that <> should become () and not $().
Some background to help clarify: In Unix shells, parenthesis () are used to run commands in a subshell, so for example, all output goes to the pipe: $ echo one; echo two | nl one 1 two $ (echo one; echo two) | nl 1 one 2 two $() is the modern equivalent of backquotes `` in Unix shells, and can be nested. It is also logical: () runs a group of commands and $() captures the result as a string: $ hg paths default ssh://h...@hg.paremus.com:24/posh $ project=$(basename $(hg paths default)) $ echo $project posh However in RFC132, we rarely need to capture output as strings - we can use the returned objects directly, so the above could look like this in RFC132: > project = (basename (hg paths default)) or if 'hg paths default' returned a File object: > project = (hg paths default) getName Shell backquotes are similar to the 'tac' command in RFC132, which captures the output of a command and returns it as a string: assuming grep prints to stdout and returns boolean to indicate whether it found a match: This sets b to the boolean result of grep: % b = <bundles | grep felix> 000000 ACT org.apache.felix.framework-1.8.1 % echo $b true We can use tac to capture the output of grep as a string: % b = <bundles | grep felix | tac> % echo $b 000000 ACT org.apache.felix.framework-1.8.1true We _could_ instead define $() to capture output, as it does in Unix: % b = $(bundles | grep felix) Derek 2009/7/17 Peter Kriens <peter.kri...@aqute.biz> > I am not sure I see why we need $( ... ) for evaluation, instead of ( ... > )? > > Kind regards, > > Peter Kriens > > > > > > On 16 jul 2009, at 16:22, Derek Baum wrote: > > 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 >>> >>> >>> >