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
