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/
