For simplicity, should we not just have () and not $(), seeing that ()
can be done with tac?
Kind regards,
Peter Kriens
On 11 aug 2009, at 14:20, Guillaume Nodet wrote:
I'd like to tackle this issue but I'm still not comfortable at the
meaning
of $() and ().
The problem I have is whether the output should be evaluated or not.
For example, if we consider () to be equivalent to <>
echo a => "a"
echo echo a => "echo a"
echo a ; echo b => "ab"
Now, when using parenthesis, we have the following options
(echo echo a) => "a" or "echo a"
I think it should be "echo a", else we can't really use it for
grouping
commands for piping:
e = { echo $0 } ; (e a b | capture)
This would fail because "e a b" would be evaluated to "a", then
capture,
but the resulting value is not a command, so a command not found
exception
would be thrown.
I think it would be more intuitive for the evaluation to be the
differenciator between () and $().
So we'd have:
echo echo a => "echo a"
(echo echo a) => "echo a"
((echo echo a)) => "echo a"
$(echo echo a) => "a"
Thoughts ?
On Wed, Jul 22, 2009 at 12:43, Hiram Chirino<chir...@gmail.com> wrote:
On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <derek.b...@paremus.com>
wrote:
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
+1. The fact of the matter is the 'casual' users of the shell will
NOT be
aware of the more powerful underlying type system that is available
via
arguments and return types. These users will prefer to work with
stdout
results since it's output is 'self-documenting'. Support for
constructs
like $(...) will make these kinds of user's lives easier.
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
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
