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
