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://[email protected]: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 <[email protected]>
> 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 <[email protected]>
>>
>>
>>> 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
>>>
>>>
>>>
>
