2009/8/11 Guillaume Nodet <gno...@gmail.com>
> I'd like to tackle this issue but I'm still not comfortable at the meaning
> of $() and ().
I think I may have complicated this issue by introducing $().
I no longer think $() is needed.
I think we can change <> directly to () without changing their semantics.
>
> The problem I have is whether the output should be evaluated or not.
The output i.e. stdout should not be evaluated. If we need to do capture it
RFC132 proposes a 'tac' command.
The first word after opening ( should be treated as a command and cause a
failure if the command is not found.
>
> 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:
yes, I agree.
>
>
> 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"
agree.
>
> (echo echo a) => "echo a"
agree.
>
> ((echo echo a)) => "echo a"
I think this should fail with command not found: a
If the inner evaluation is not intended to produce a command:
(echo result: (echo echo a)) => result: a
The Unix analog (which also fails) is:
bash% $($(echo echo a))
-bash: a: command not found
>
> $(echo echo a) => "a"
This is equivalent to (echo echo a | tac)
At first I liked the idea of removing 'tac' and replacing it with $() - but
'tac' is actually more flexible:
e.g. write to file as RFC132 doesn't provide Unix-like IO redirection:
bundles | tac -f b.txt
I have also found it useful to add 'tac --list' that returns the output as a
list, rather than a String, as this can then be iterated over using each:
each <bundles | grep felix> { echo felix bundle: $it }
Derek
>
>
> 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
>
