felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Derek Baum <derek.b...@paremus.com>
Subject Re: Gogo
Date Tue, 11 Aug 2009 21:48:50 GMT
yes, I agree that it is a problem that you cannot invoke methods on String
objects.

The String class contains many useful methods e.g. startsWith(), that should
be directly usable in Gogo without having to create equivalent commands.

I also want to raise another problem:

RFC132 commands are designed to be easy to create, allowing direct use of
System.out

void echo1(String[] args) {
    StrinbgBuilder buf = new StringBuilder();
    for (String arg : args) {
        if (buf.length() > 0)
            buf.append(' ');
        buf.append(arg)
    }
    System.out.println(buf.toString());
}

but it also allows commands that return values:

String echo2(String[] args) {
    StrinbgBuilder buf = new StringBuilder();
    for (String arg : args) {
        if (buf.length() > 0)
            buf.append(' ');
        buf.append(arg)
    }
    return(buf.toString());
}

Both these command cause grep to match 'hello':

echo1 hello | grep hello
echo2 hello | grep hello

This is expected with echo1, as it writes to System.out.
It is more surprising that echo2 also works, as it doesn't write to
System.out.

In this case, the runtime is implicitly writing the result of 'echo2 hello'
into the pipe.

This is convenient, as it lets commands that don't write to System.out be
used in pipelines.

However, it can also get in the way.

I have a grep command that writes to System.out and returns a boolean,
depending on whether it matched:

bundles | grep felix | wc

but in this case, the wc command gets the result of grep (true) as well as
the output from grep, which not wanted, so I would like some way of
disabling this behaviour.


I think we should raise these as Jira issues, so we keep future comments
distinct.


Derek


2009/8/11 Guillaume Nodet <gnodet@gmail.com>

> 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<gnodet@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<chirino@gmail.com> wrote:
> >> On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <derek.baum@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://hg@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.kriens@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.kriens@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message