I also want to raise another problem, which is the undeterministic
aspect of the evaluation.
A statement is considered a comment if the first argument is a string,
else it assumes it represents a method call.
Thus, you can't call a method on a string. This would be a problem
when using things like
$a getClass
where the execution would be different depending of the type of $a
On Tue, Aug 11, 2009 at 14:20, Guillaume Nodet<gno...@gmail.com> 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
>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
