You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Charles Moulliard <cm...@gmail.com> on 2009/07/13 10:45:40 UTC
Karaf - Gogo - Help !
Hi,
I have done a build of Apache Felix Karaf this morning in order to test it
but unfortunately Gogo does not seem to like Windows :
Here is a snapshot of command used :
karaf@root> karaf@root> help
help
karaf@root> karaf@root> ?
?
karaf@root> karaf@root> help
help
karaf@root> karaf@root>
We can't have access to help !
Where can I found the list of commands that we can use with Gogo (compare to
gshell) ?
Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
Re: Karaf - Gogo - Help !
Posted by Charles Moulliard <cm...@gmail.com>.
I think so even if it is mentioned in the header that this is the case :
D:\Dvlpt\Java\workspace-ganymede\x3s\server\apache-felix-karaf-1.2.0-SNAPSHOT\bin>karaf
__ __ ____
/ //_/____ __________ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Felix Karaf (1.2.0-SNAPSHOT)
Type 'help' for more information.
karaf@root> bundles
000000 ACT org.eclipse.osgi-3.5.0.v20090520
000001 ACT org.apache.felix.configadmin-1.0.4
000002 ACT org.apache.felix.prefs-1.0.2
000003 ACT blueprint-bundle-1.0.0.SNAPSHOT
000004 ACT org.ops4j.pax.logging.pax-logging-service-1.3.1.SNAPSHOT
000005 ACT org.ops4j.pax.logging.pax-logging-api-1.3.1.SNAPSHOT
000006 ACT org.ops4j.pax.url.wrap-0.3.3
000007 ACT org.ops4j.pax.url.mvn-0.3.3
000008 ACT org.apache.felix.karaf.gshell.packages-1.2.0.SNAPSHOT
000009 ACT org.apache.felix.karaf.deployer.spring-1.2.0.SNAPSHOT
000010 ACT org.apache.mina.core-2.0.0.M6
000011 ACT org.apache.felix.karaf.deployer.blueprint-1.2.0.SNAPSHOT
000012 ACT org.apache.felix.karaf.gshell.osgi-1.2.0.SNAPSHOT
000013 ACT org.apache.felix.karaf.management-1.2.0.SNAPSHOT
000014 ACT org.apache.felix.karaf.gshell.console-1.2.0.SNAPSHOT
000015 ACT org.apache.felix.karaf.gshell.config-1.2.0.SNAPSHOT
000016 ACT org.apache.felix.karaf.gshell.admin-1.2.0.SNAPSHOT
000017 ACT org.apache.felix.karaf.jaas.config-1.2.0.SNAPSHOT
000018 ACT org.osgi.impl.bundle.jmx-4.2.0.200907080519
000019 ACT org.apache.felix.karaf.gshell.features-1.2.0.SNAPSHOT
000020 ACT org.apache.felix.karaf.gshell.ssh-1.2.0.SNAPSHOT
000021 ACT org.apache.felix.karaf.deployer.features-1.2.0.SNAPSHOT
000022 ACT org.apache.felix.karaf.gshell.commands-1.2.0.SNAPSHOT
000023 ACT sshd-core-1.0.0.SNAPSHOT
000024 ACT org.apache.felix.karaf.gshell.log-1.2.0.SNAPSHOT
000025 ACT org.apache.felix.karaf.jaas.modules-1.2.0.SNAPSHOT
000026 ACT org.apache.felix.gogo.runtime-0.9.0.SNAPSHOT
000027 ACT org.apache.felix.karaf.deployer.filemonitor-1.2.0.SNAPSHOT
karaf@root> karaf@root> log
log
karaf@root> karaf@root> ?
?
karaf@root> karaf@root> help
help
karaf@root> karaf@root> set INFO
karaf@root> karaf@root> packages
packages
karaf@root> karaf@root> imports 1
OSGi System Bundle (0): org.osgi.framework; version="1.5.0"
OPS4J Pax Logging - API (5): org.osgi.service.log; version="1.3.0"
karaf@root> karaf@root>
Another issue is that the name of the command does not appear on the shell.
So, by example, when you type the word : packages or log, the console is
refreshed but you have no idea where you are in the tree of the commands
And the last but not the least is that question are double :
karaf@root> karaf@root> update 27
You are about to access system bundle 27. Do you want to continue (yes/no):
You are about to access system bundle 27. Do you want to continue (yes/no):
Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
On Mon, Jul 13, 2009 at 4:27 PM, Hiram Chirino <ch...@gmail.com> wrote:
> I don't think the help command is supported yet..
>
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found. This
> seems to work fine if you pass an argument to a command. It this a
> 'feature' or a bug?
>
> Regards,
> Hiram
>
>
> On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard <cmoulliard@gmail.com
> >wrote:
>
> > Hi,
> >
> > I have done a build of Apache Felix Karaf this morning in order to test
> it
> > but unfortunately Gogo does not seem to like Windows :
> >
> > Here is a snapshot of command used :
> >
> > karaf@root> karaf@root> help
> > help
> > karaf@root> karaf@root> ?
> > ?
> > karaf@root> karaf@root> help
> > help
> > karaf@root> karaf@root>
> >
> > We can't have access to help !
> > Where can I found the list of commands that we can use with Gogo (compare
> > to
> > gshell) ?
> >
> > Regards,
> >
> > Charles Moulliard
> > Senior Enterprise Architect
> > Apache Camel Committer
> >
> > *****************************
> > blog : http://cmoulliard.blogspot.com
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://fusesource.com/
>
Re: Karaf - Gogo - Help !
Posted by Derek Baum <de...@paremus.com>.
2009/7/13 Hiram Chirino <ch...@gmail.com>
> I don't think the help command is supported yet..
>
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found. This
> seems to work fine if you pass an argument to a command. It this a
> 'feature' or a bug?
It's a 'feature', but it can be fixed.
See https://issues.apache.org/jira/browse/FELIX-1325
Derek
>
>
> Regards,
> Hiram
>
>
> On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard <cmoulliard@gmail.com
> >wrote:
>
> > Hi,
> >
> > I have done a build of Apache Felix Karaf this morning in order to test
> it
> > but unfortunately Gogo does not seem to like Windows :
> >
> > Here is a snapshot of command used :
> >
> > karaf@root> karaf@root> help
> > help
> > karaf@root> karaf@root> ?
> > ?
> > karaf@root> karaf@root> help
> > help
> > karaf@root> karaf@root>
> >
> > We can't have access to help !
> > Where can I found the list of commands that we can use with Gogo (compare
> > to
> > gshell) ?
> >
> > Regards,
> >
> > Charles Moulliard
> > Senior Enterprise Architect
> > Apache Camel Committer
> >
> > *****************************
> > blog : http://cmoulliard.blogspot.com
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://fusesource.com/
>
Re: Karaf - Gogo - Help !
Posted by Hiram Chirino <ch...@gmail.com>.
+1 on trying encouraging RFC132 to not surprise old unix gurus too much.
On Tue, Jul 14, 2009 at 3:59 AM, Derek Baum <de...@paremus.com> wrote:
> yes,
>
> ${x} actually defines a closure {...} and then immediately expands it.
> Commands typed directly into the shell also result in a closure being
> created and executed, so it is difficult to distinguish between:
>
> > x
>
> where we'd like it to fail with 'unknown command'
>
> and
>
> > ${x}
>
> where we'd like it to behave like $x
>
> RFC132 is keen to minimise unnecessary typing and so variables can be
> expanded directly without enclosing in {}.
>
> However, as in Unix shells,you sometimes need to delimit variables from the
> following text,
> for example x = "${ab}c". This is still possible in Gogo, without using ${}
> - e.g. "$ab'c'", but it is not as intuitive as "${ab}c" which is commonly
> used elsewhere.
>
> Derek
>
>
> 2009/7/14 Guillaume Nodet <gn...@gmail.com>
>
> > I think this is a feature, but I agree with you and I'd like to
> > consider it a bug too. However I think that's also why ${x}
> > evaluation works...
> >
> > On Monday, July 13, 2009, Hiram Chirino <ch...@gmail.com> wrote:
> > > I don't think the help command is supported yet..
> > >
> > > But on related note... to the gogo developers: I would have expected a
> > > command not found error when you type in a command that's not found.
> > This
> > > seems to work fine if you pass an argument to a command. It this a
> > > 'feature' or a bug?
> > >
> > > Regards,
> > > Hiram
> > >
> > >
> > > On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard <
> cmoulliard@gmail.com
> > >wrote:
> > >
> > >> Hi,
> > >>
> > >> I have done a build of Apache Felix Karaf this morning in order to
> test
> > it
> > >> but unfortunately Gogo does not seem to like Windows :
> > >>
> > >> Here is a snapshot of command used :
> > >>
> > >> karaf@root> karaf@root> help
> > >> help
> > >> karaf@root> karaf@root> ?
> > >> ?
> > >> karaf@root> karaf@root> help
> > >> help
> > >> karaf@root> karaf@root>
> > >>
> > >> We can't have access to help !
> > >> Where can I found the list of commands that we can use with Gogo
> > (compare
> > >> to
> > >> gshell) ?
> > >>
> > >> Regards,
> > >>
> > >> Charles Moulliard
> > >> Senior Enterprise Architect
> > >> Apache Camel Committer
> > >>
> > >> *****************************
> > >> blog : http://cmoulliard.blogspot.com
> > >>
> > >
> > >
> > >
> > > --
> > > 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
> >
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
Re: Gogo
Posted by Peter Kriens <pe...@aqute.biz>.
For simplicity, should we not just have () and not $(), seeing that ()
can be done with tac?
Kind regards,
Peter Kriens
On 11 aug 2009, at 14:20, Guillaume Nodet 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<ch...@gmail.com> wrote:
>> On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <de...@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 <pe...@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 <pe...@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
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
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 <gn...@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<gn...@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<ch...@gmail.com> wrote:
> >> On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <de...@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 <pe...@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 <pe...@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
>
Re: Gogo
Posted by Guillaume Nodet <gn...@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<gn...@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<ch...@gmail.com> wrote:
>> On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <de...@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 <pe...@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 <pe...@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
Re: Gogo
Posted by David Savage <da...@paremus.com>.
Hi there,
Seems like a good time to wade into the discussion ;) it seems like it
could be beneficial to start looking at the TSL syntax from the point
of view of a formal grammar specification such as ANTLR? Currently
most of the tests are via unit tests and the parsing is done by custom
java code. The danger is that without a formal grammar specification
we may "fix" one part of the parser to handle one use case only to
expose a secondary problem. Unit tests are certainly one way to catch
this but they can only be as good as the number of tests we define,
where as I believe a logically consistent grammar is a test in itself?
Of course this may also be a fools errand (firstly as I have no
experience with antlr grammars) and looking at this link (which I came
at by searching for "bash antlr grammar" in google) it may not even be
possible - though the post is very old:
http://www.antlr.org/pipermail/antlr-interest/2006-May/016235.html
Wondering if there are any language experts following this list who can comment?
I'm also wondering if it may make sense to extract the shell that
interprets the commands and the runtime that provides the commands. I
really like the TSL impl but in the end it's just one possible way of
running commands? One of the really nice things about RFC 132 is it
provides a common way for developers to add commands in osgi, but how
we refer to those commands is a secondary issue, here thinking of the
sh,csh,bash type debate...
Finally though the echo echo type debate is good for simplifying the
problem down in unit tests in email it does depend on how we think
echo is defined. Does echo return a value or does it write the result
to the stream or both (?!). It seems like it would be useful to define
a set of commands for debate that are unambiguous? I guess these could
be abstract commands which could go on a wiki or some such? Some
examples:
nsc -> no such command
void -> command that does nothing and returns nothing
echo -s hello -> echo "hello" to stream
echo -v -> echo "hello" to value
echo -sv hello -> echo "hello" to stream and value
array a b c -> returns [a,b,c] as an array
Others?
Just my 2 pence anyway...
Regards,
Dave
On Thu, Aug 20, 2009 at 5:45 PM, Guillaume Nodet<gn...@gmail.com> wrote:
> On Thu, Aug 20, 2009 at 15:40, Derek Baum <de...@paremus.com> wrote:
>
>>
>> > I disagree with having eval as a command. The reason is that is has two
>> sides effects:
>> > * all parameters are evaluated once more, so that $xxx expansion will be
>> > done once again, and it could lead to unwanted results
>>
>> this is offset by not implicitly evaluating the args - re-evaluation
>> only occurs when explicitly invoking eval.
>>
>> > * all parameters are converted to strings, which i think is not what is
>> expected.
>>
>> I'm not sure this is a problem. The 3.patch eval is like eval in bash,
>> and can be used to re-evaluate a string as a script.
>>
>> Derek
>>
>
>
> Well, I think this really lead to undesirable effects:
>> x = <bundle 0>
> ...
>> $x toString
> org.apache.felix.framework [0]
>> eval $x toString
> Command not found *:org.apache.felix.framework
>
> I think both should be identical.
> If you want to evaluate the arguments as a fully new command line, you could
> use quoting
>> eval "$x toString"
> But the opposite can't be done.
> So I still think we should come back to my earlier proposal about making it
> a real keyword instead of a command.
>
> I think this is independant of wether arguments are re-parsed, though they
> are related.
>
> I've also spotted another problem, but this looks like a different problem:
>> echo "$x"
> java.lang.Exception: Unable to convert from [org.apache.felix.framework [0]]
> to java.util.List<java.lang.String>(error converting collection entry)
>
> I would have thought it would behave the same as
>> echo <$x toString>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Aug 20, 2009 at 15:40, Derek Baum <de...@paremus.com> wrote:
>
> > I disagree with having eval as a command. The reason is that is has two
> sides effects:
> > * all parameters are evaluated once more, so that $xxx expansion will be
> > done once again, and it could lead to unwanted results
>
> this is offset by not implicitly evaluating the args - re-evaluation
> only occurs when explicitly invoking eval.
>
> > * all parameters are converted to strings, which i think is not what is
> expected.
>
> I'm not sure this is a problem. The 3.patch eval is like eval in bash,
> and can be used to re-evaluate a string as a script.
>
> Derek
>
Well, I think this really lead to undesirable effects:
> x = <bundle 0>
...
> $x toString
org.apache.felix.framework [0]
> eval $x toString
Command not found *:org.apache.felix.framework
I think both should be identical.
If you want to evaluate the arguments as a fully new command line, you could
use quoting
> eval "$x toString"
But the opposite can't be done.
So I still think we should come back to my earlier proposal about making it
a real keyword instead of a command.
I think this is independant of wether arguments are re-parsed, though they
are related.
I've also spotted another problem, but this looks like a different problem:
> echo "$x"
java.lang.Exception: Unable to convert from [org.apache.felix.framework [0]]
to java.util.List<java.lang.String>(error converting collection entry)
I would have thought it would behave the same as
> echo <$x toString>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
>> > The patch for FELIX-1325 alter this behavior and reject any assignment
>> with multiple arguments.
>>
>> I don't think that this is necessary. RFC-132 explicitly allows this
>> (4.13 Command calling):
>> <string> '=' <value> + execute values as statements, set
>> result as variable
>>
>> However, if a single value is used in an assignment, then it shouldn't
>> be executed, so:
>> x = echo
>> does NOT set x to "" (the result of echo).
>>
>
> Isn't that a bit worrying to have the same syntax behaving in different ways
> depending on the number of arguments ?
bash behaves like this - you only have to quote assignments containing
multiple words:
$ x=hello
$ x=hello world
-bash: world: command not found
$ x='hello world'
However, I can also see the argument for making execution explicit, so
if you wanted to assign the result of executing hello, RFC-132 allows:
x = hello world
but I agree it is clearer to be explicit:
x = <hello world>
Note: FELIX-1471-2.patch does NOT currently allow this:
> x = <echo hello world>
java.lang.IllegalArgumentException: Assignements can only have a
single agument
Surely the result of <> should be a single argument?
You now have to quote the <>, which is not intuitive:
> x = "<echo hello world>"
hello world
> For re-parsing the results, i think this is an important feature, regardless
> of eval()
> If we don't reparse the arguments, then
>> a = "echo b"; eval $a
> would throw an unknown command exception "echo b" as "echo b" would be
> considered a single argument.
This depends on the implementation of eval.
In FELIX-1471-3.patch, I have removed the implicit re-parsing and
implemented eval as (effectively):
session.execute(args);
eval can then be used to explicitly re-parse as required:
Our two approaches (2.patch and 3.patch) initially seem similar:
2.patch:
> x = "<echo echo a>"
echo a
> eval $x
a
3.patch:
> x = <echo echo a>
echo a
> eval $x
a
However, more complex examples, yield different results:
2.patch:
> eval "echo hello"
java.lang.IllegalArgumentException: Command not found: *:echo hello
> x = "echo a; echo b"
echo a; echo b
> eval $x
a
result should be 'b'?
> prog = 'x = {echo xxx $it}; x hello'
x = org.apache.felix.gogo.runtime.shell.Closure@87e9b2; x hello
> eval $prog
org.apache.felix.gogo.runtime.shell.Closure@87e9b2
3.patch:
> eval "echo hello"
hello
> x = "echo a; echo b"
echo a; echo b
> eval $x
b
> prog = 'x = {echo xxx $it}; x hello'
x = {echo xxx $it}; x hello
> eval $prog
xxx hello
> I think in this case, we should have
>> $a
> b
>> eval $a
> b
2.patch alllows:
> $a
b
while 3.patch requires explicit eval:
> eval $a
b
> $a
java.lang.IllegalArgumentException: Command not found: *:echo b
> I disagree with having eval as a command. The reason is that is has two sides effects:
> * all parameters are evaluated once more, so that $xxx expansion will be
> done once again, and it could lead to unwanted results
this is offset by not implicitly evaluating the args - re-evaluation
only occurs when explicitly invoking eval.
> * all parameters are converted to strings, which i think is not what is expected.
I'm not sure this is a problem. The 3.patch eval is like eval in bash,
and can be used to re-evaluate a string as a script.
Derek
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Aug 20, 2009 at 13:40, Derek Baum <de...@paremus.com> wrote:
> >> FELIX-1471 proposes using () for grouping and $() for evaluation.
> >> So the above example would become:
> >> > x = (echo aa; (echo ab; echo ac | grep -n a | tac))
> >>
> >
> > Not sure about this one.
> > I guess i've been fooled in my testing by the fact that when evaluating a
> > command, you have two results: the output on the console and the object
> > returned by the command.
> > We need to handle both at some point.
> > But for this, we need to exactly define when the returned object will be
> > printed to the console (or the piped output stream).
> >
>
> Yes, I raised FELIX-1474 about the implicit writing of command results to
> pipes.
> We should discuss this separately to avoid complicating this thread.
>
>
> > The next question is what happens when "..." is defined by multiple
> tokens:
> >> x = a b
> > What does that mean ? I'm not sure of the answer.
>
> It assigns x the result of the command: a b
> See Peter's initial comment in this thread:
>
> >>> a = hello world
> >>>Is NOT a = "hello world". And I do not think it should be.
>
>
> > The patch for FELIX-1325 alter this behavior and reject any assignment
> with multiple arguments.
>
> I don't think that this is necessary. RFC-132 explicitly allows this
> (4.13 Command calling):
> <string> '=' <value> + execute values as statements, set
> result as variable
>
> However, if a single value is used in an assignment, then it shouldn't
> be executed, so:
> x = echo
> does NOT set x to "" (the result of echo).
>
Isn't that a bit worrying to have the same syntax behaving in different ways
depending on the number of arguments ?
>
>
> >> FWIW I still think it is possible to solve this without introducing $(),
>
> > This made me think a bit differently. The real issue is not about
> grouping
> > / evaluating.
> > Currently, the < > operator means: evaluate the command line inside and
> > return the value.
> > The real problem comes from the fact that the number of evaluations is
> > wrong.
> > So I came up with a new simplier patch that I think solve the issue while
> > keeping <> as you mentionned.
> > I've attached it to FELIX-1471 and it's available at
> >
> https://issues.apache.org/jira/secure/attachment/12417086/FELIX-1471-2.patch
> > It also includes a fix for FELIX-1325 and FELIX-1498, and introduce a new
> > "eval" keyword.
>
>
> > Let me know what you think, but this looks like a cleaner solution.
>
> Yes, this is much cleaner. I mentioned the use of an eval function
> earlier in this thread.
>
> I have tested FELIX-1471-2.patch and although mostly OK, e.g.
>
> karaf@root> <echo a a; <echo a b; echo ac | grep -n a | tac>>
> a a
> 1 a b 3 ac
>
> as expected.
>
> I don't like the new assignment restriction:
>
> karaf@root> x = <echo a a; <echo a b; echo ac | grep -n a | tac>>
> a a
> pipe: java.lang.IllegalArgumentException: Assignements can only have a
> single argument
>
>
> karaf@root> x = <echo hello world>
> hello world
> karaf@root> echo $x
> null
>
> ensure we are using osgi:echo (which returns a String):
> karaf@root> SCOPE=osgi:*
> osgi:*
>
> karaf@root> x = <echo hello world>
> pipe: java.lang.IllegalArgumentException: Assignements can only have a
> single
> agument
>
> karaf@root> x = '<echo hello world>'
> hello world
>
>
> I have further simplified FELIX-1471-2.patch and created FELIX-1471-3.patch
>
> https://issues.apache.org/jira/secure/attachment/12417131/FELIX-1471-3.patch
>
> 1. removes restriction that assignments only have single argument
> 2. removes code to re-parse string results - not needed now we have eval()
> (eval is now a regular command like tac, rather than a special
> keyword).
For re-parsing the results, i think this is an important feature, regardless
of eval()
If we don't reparse the arguments, then
> a = "echo b"; eval $a
would throw an unknown command exception "echo b" as "echo b" would be
considered a single argument.
I think in this case, we should have
> $a
b
> eval $a
b
If you don't want this behavior, you can enclose $a in double quotes.
I disagree with having eval as a command. The reason is that is has two
sides effects:
* all parameters are evaluated once more, so that $xxx expansion will be
done once again, and it could lead to unwanted results
* all parameters are converted to strings, which i think is not what is
expected.
I much rather the previous behavior and keep eval as a keyword instead.
>
> 3. updated tests
>
> Let me know if this works for you.
>
> Derek
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
>> FELIX-1471 proposes using () for grouping and $() for evaluation.
>> So the above example would become:
>> > x = (echo aa; (echo ab; echo ac | grep -n a | tac))
>>
>
> Not sure about this one.
> I guess i've been fooled in my testing by the fact that when evaluating a
> command, you have two results: the output on the console and the object
> returned by the command.
> We need to handle both at some point.
> But for this, we need to exactly define when the returned object will be
> printed to the console (or the piped output stream).
>
Yes, I raised FELIX-1474 about the implicit writing of command results to pipes.
We should discuss this separately to avoid complicating this thread.
> The next question is what happens when "..." is defined by multiple tokens:
>> x = a b
> What does that mean ? I'm not sure of the answer.
It assigns x the result of the command: a b
See Peter's initial comment in this thread:
>>> a = hello world
>>>Is NOT a = "hello world". And I do not think it should be.
> The patch for FELIX-1325 alter this behavior and reject any assignment with multiple arguments.
I don't think that this is necessary. RFC-132 explicitly allows this
(4.13 Command calling):
<string> '=' <value> + execute values as statements, set
result as variable
However, if a single value is used in an assignment, then it shouldn't
be executed, so:
x = echo
does NOT set x to "" (the result of echo).
>> FWIW I still think it is possible to solve this without introducing $(),
> This made me think a bit differently. The real issue is not about grouping
> / evaluating.
> Currently, the < > operator means: evaluate the command line inside and
> return the value.
> The real problem comes from the fact that the number of evaluations is
> wrong.
> So I came up with a new simplier patch that I think solve the issue while
> keeping <> as you mentionned.
> I've attached it to FELIX-1471 and it's available at
> https://issues.apache.org/jira/secure/attachment/12417086/FELIX-1471-2.patch
> It also includes a fix for FELIX-1325 and FELIX-1498, and introduce a new
> "eval" keyword.
> Let me know what you think, but this looks like a cleaner solution.
Yes, this is much cleaner. I mentioned the use of an eval function
earlier in this thread.
I have tested FELIX-1471-2.patch and although mostly OK, e.g.
karaf@root> <echo a a; <echo a b; echo ac | grep -n a | tac>>
a a
1 a b 3 ac
as expected.
I don't like the new assignment restriction:
karaf@root> x = <echo a a; <echo a b; echo ac | grep -n a | tac>>
a a
pipe: java.lang.IllegalArgumentException: Assignements can only have a
single argument
karaf@root> x = <echo hello world>
hello world
karaf@root> echo $x
null
ensure we are using osgi:echo (which returns a String):
karaf@root> SCOPE=osgi:*
osgi:*
karaf@root> x = <echo hello world>
pipe: java.lang.IllegalArgumentException: Assignements can only have a single
agument
karaf@root> x = '<echo hello world>'
hello world
I have further simplified FELIX-1471-2.patch and created FELIX-1471-3.patch
https://issues.apache.org/jira/secure/attachment/12417131/FELIX-1471-3.patch
1. removes restriction that assignments only have single argument
2. removes code to re-parse string results - not needed now we have eval()
(eval is now a regular command like tac, rather than a special keyword).
3. updated tests
Let me know if this works for you.
Derek
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Aug 19, 2009 at 18:48, Derek Baum <de...@paremus.com> wrote:
> OK, I think I now understand the problem FELIX-1471 is trying to solve.
> Sorry it's taken so long :-(
>
> I have my own example that demonstrates it,
> just to confirm that I have the same understanding.
>
> > x = <echo aa; <echo ab; echo ac | grep -n a | tac>>
> aa
> 1 ab 3 ac
> IllegalArgumentException: Command not found: *:1
>
> The return value of tac (and the value assigned to x) is
> " 1 ab 3 ac".
> The problem is that the <> used for grouping also evaluates the result,
> causing the exception.
>
Exactly.
>
> FELIX-1471 proposes using () for grouping and $() for evaluation.
> So the above example would become:
> > x = (echo aa; (echo ab; echo ac | grep -n a | tac))
>
Not sure about this one.
I guess i've been fooled in my testing by the fact that when evaluating a
command, you have two results: the output on the console and the object
returned by the command.
We need to handle both at some point.
But for this, we need to exactly define when the returned object will be
printed to the console (or the piped output stream).
This example also use an assignement, which we need to clearly defines what
it means.
When you have "x = ...", it intuitively implies that x will take the value
expressed by "..." whatever it is.
So if we have a simple value:
> x = a
it means x will store the string "a"
If you have
> x = { echo $args }
it means x will store the closure.
The next question is what happens when "..." is defined by multiple tokens:
> x = a b
What does that mean ? I'm not sure of the answer.
Currently, everything following the = is considered a closure that is
executed, so
> x = echo a
would mean x store the string "a".
This only works because FELIX-1325 has not been applied, so that
> x = a
also works, because executing "a" would return "a".
However,
> x = echo
would currently store "" in x, which might be confusing.
The patch for FELIX-1325 alter this behavior and reject any assignment with
multiple arguments.
So that
> x = a ; echo $x
a
> x = "echo a" ; echo $x
echo a
> x = $(echo a) ; echo $x
a
So I think the following should be written:
> x = (echo aa; (echo ab; echo ac | grep -n a | tac)) ; echo $x
1 ab 3 ac
> and
> > installandstart = { <installbundle <$baseURI resolve $0>> start }
>
> would become:
> > installandstart = { $(installbundle $($baseURI resolve $0)) start }
>
Right, I agree.
>
> FWIW I still think it is possible to solve this without introducing $(),
> just by stopping <> at the start of a statement from evaluating:
>
> karaf@root> x = <echo aa; <echo ab; echo ac | grep -n a | tac>>
> aa
> 1 ab 3 ac
> karaf@root> <osgi:echo a b>
> a b
> karaf@root> <<osgi:echo a b>>
> a b
> karaf@root> <<bundle 0> tostring>
> org.apache.felix.framework [0]
>
This made me think a bit differently. The real issue is not about grouping
/ evaluating.
Currently, the < > operator means: evaluate the command line inside and
return the value.
The real problem comes from the fact that the number of evaluations is
wrong.
So I came up with a new simplier patch that I think solve the issue while
keeping <> as you mentionned.
I've attached it to FELIX-1471 and it's available at
https://issues.apache.org/jira/secure/attachment/12417086/FELIX-1471-2.patch
It also includes a fix for FELIX-1325 and FELIX-1498, and introduce a new
"eval" keywork.
So we should have
> echo a
a
> <echo a>
a
> <<echo a>>
a
> eval echo echo a
echo a
> eval <echo echo a>
a
Let me know what you think, but this looks like a cleaner solution.
> However, the $() approach works fine too and so I'm happy to support this,
> so we can get this issue resolved.
>
> I have tested the latest FELIX-1471.patch and it mostly works OK:
>
> > echo aa; (echo ab; echo ac | grep -n a | tac)
> aa
> 1 ab 3 ac
>
> but fails when the result of () is in an assignment:
>
> karaf@root> x = (echo aa; (echo ab; echo ac | grep -n a | tac))
> org.osgi.framework.InvalidSyntaxException: expected value|substring
> at org.apache.felix.framework.FilterImpl.<init>(FilterImpl.java:81)
> at
> org.apache.felix.framework.Felix.getServiceReferences(Felix.java:2893)
>
> Derek
>
> 2009/8/18 Guillaume Nodet <gn...@gmail.com>
> >
> > On Tue, Aug 18, 2009 at 09:17, Derek Baum <de...@paremus.com>
> wrote:
> >
> > > 2009/8/17 Guillaume Nodet <gn...@gmail.com>
> > >
> > > >
> > > > So in short, the patch does the following:
> > > > * replace <> with $()
> > > > * use ( ) for grouping commands when on the edge of the command
> > > > * make the number of evaluation predictable
> > > > * have a syntax and semantic which is mostly (fully) in sync with
> bash
> > > > * re-evaluate / split expanded arguments that are not quoted
> > >
> > >
> > >
> > > I can still see no reason for having () and $() as two separate
> operators.
> > > This unncessarily compllicates syntax without adding any new
> capability.
> > >
> > > You previously gave the following example to demonstrate the need for a
> > > separate grouping operator:
> > >
> > > >The grouping operator is imho needed to be able to order pipes and
> > > columns:
> > > > (echo a ; echo b) | tac
> > > > echo a ; (echo b | tac)
> > >
> > > However, this example works fine with the existing <> execution quotes:
> > >
> > > karaf@root> <echo a; echo b> | tac
> > > ab
> > > karaf@root> echo a; <echo b | tac>
> > > a
> > > b
> > >
> > > Do you have any other example or use case that demonstrates the need
> for a
> > > separate grouping operator?
> > >
> > > () in bash is NOT only used for grouping - it executes the command
> within
> > > (), just like the existing <>.
> > > $() in bash executes and captures stdout into a string - equivalent to
> > > <command args | tac> in gogo.
> > >
> >
> > Well the key difference between those operators in bash is the number of
> > times the evaluation happen.
> >
> > ( ) does not change the number of times a command will be evaluated,
> that's
> > why i call it grouping.
> > What i mean is that if you remove the ( ), the commands will be executed
> the
> > same number of time.
> > echo a => echo a
> > ( echo a ) => echo a
> > ( ( echo a ) ) => echo a
> > All of those will produce the same result.
> >
> > $( ) will increment the number of evaluation each time it's used, and is
> > therefore not idemptotent.
> > echo echo echo a => echo echo a
> > $(echo echo echo a) => echo a
> > $( $( echo echo echo a) ) => a
> >
> > I don't really see how we can conflate both operators using < > or any
> other
> > syntax.
> > With the current state of gogo, you're not really sure how many times
> > evaluation will happen.
> >
> >
> > >
> > > To try to understand the need for separate () and $() operators, I have
> > > taken the gogo TestParser.java from the FELIX-1471.patch and replaced
> both
> > > $() and () with <>. I then ran the test against the unpatched code.
> > >
> > > All tests worked except some newly added tests within
> > > testGroupingAndEvaluation() like:
> > >
> > > assertEquals("a", c.execute("<echo echo a>") + "");
> > >
> > > This fails because <echo echo a> evaluates to the String "echo a",
> which is
> > > then evaluated as a command and the command 'echo a' is not found.
> > >
> > > assertEquals("a", c.execute("$(echo echo a)") + "");
> > >
> > > This works because of the complex re-parsing done by $() that you
> describe
> > > below.
> >
> >
> > Right, and I think this reparsing of arguments should be done anyway. So
> > maybe we need a separate jira for that one.
> >
> > I think I understood where our uncomprehension comes from. I first
> started
> > to have a look at FELIX-1325 (throwing an exception when the can't be
> found,
> > even if it has no arguments). The problem is that all those issues are
> > linked.
> > What you describe above works only because when you have a single token
> on
> > the command line and that no command is found, the token is simply
> returned.
> > This means that in all the above examples, the number of evaluation is
> not
> > really important, because executing "a" will return "a".
> > This hides some real issues imho, as the following tests, that all pass
> on
> > trunk show:
> >
> > assertEquals("echo echo", c.execute("echo echo echo"));
> > assertEquals("echo", c.execute("<echo echo echo>"));
> > assertEquals("", c.execute("<<echo echo echo>>"));
> >
> > assertEquals("echo a", c.execute("echo echo a"));
> > assertEquals("a", c.execute("<echo echo a>"));
> > assertEquals("a", c.execute("<<echo echo a>>"));
> >
> >
> > So the behavior of < > is that it run the command(s) inside it *and*
> > evaluates it. It's not only grouping.
> >
> > Now, let's take an example:
> >
> > assertEquals("a", c.execute("echoout \"a\nb\" | grep a |
> capture"));
> > assertEquals("b", c.execute("echoout \"a\nb\" | grep b |
> capture"));
> > assertEquals("ab", c.execute("<echoout \"a\nb\" | grep a |
> capture>
> > ; <echoout \"a\nb\" | grep b | capture> | capture"));
> >
> > assertEquals("", c.execute("<echoout \"echo\ngrep\" | grep echo |
> > capture> ; <echoout \"echo\ngrep\" | grep grep | capture> | capture"));
> >
> > The first two tests are ok. The third test is equivalent to "test1 ;
> test2
> > | capture".
> > Remember that atm ';' takes precedence over '|'.
> >
> > Now the last test is the same as the third one, but with different
> values.
> > The output should be "echogrep", but isn't, due to the additional
> > evaluation.
> > The third test would also fail if we apply FELIX-1325 afaik.
> >
> >
> > >
> > > In bash, if you need to re-parse some text, you use the 'eval' command:
> > >
> > > $ eval $(echo echo '$HOME')
> > > /Users/derek
> > >
> > > We could take exactly the same approach in gogo, by adding a simple
> eval
> > > command for use on the rare occassions when it is required.
> > >
> > > Derek
> > >
> > >
> > >
> > > >
> > > >
> > > > I'm happy to discuss things further, but the major problem is related
> to
> > > > make the evaluation predictable, which sounds easy, but is not really
> ...
> > > > And this require to re-evaluate / split the expanded arguments.
> > > > See the following example:
> > > > assertEquals("a", c.execute("$($(echo echo echo a)) |
> capture"));
> > > > The "echo echo echo a" command is executed and prints "echo echo a".
> This
> > > > result is inside $() so it has to be interpreted as a full command
> line,
> > > > not
> > > > as a single argument which would be a string "echo echo a" as this
> would
> > > > return a command not found.
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > 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
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
OK, I think I now understand the problem FELIX-1471 is trying to solve.
Sorry it's taken so long :-(
I have my own example that demonstrates it,
just to confirm that I have the same understanding.
> x = <echo aa; <echo ab; echo ac | grep -n a | tac>>
aa
1 ab 3 ac
IllegalArgumentException: Command not found: *:1
The return value of tac (and the value assigned to x) is
" 1 ab 3 ac".
The problem is that the <> used for grouping also evaluates the result,
causing the exception.
FELIX-1471 proposes using () for grouping and $() for evaluation.
So the above example would become:
> x = (echo aa; (echo ab; echo ac | grep -n a | tac))
and
> installandstart = { <installbundle <$baseURI resolve $0>> start }
would become:
> installandstart = { $(installbundle $($baseURI resolve $0)) start }
FWIW I still think it is possible to solve this without introducing $(),
just by stopping <> at the start of a statement from evaluating:
karaf@root> x = <echo aa; <echo ab; echo ac | grep -n a | tac>>
aa
1 ab 3 ac
karaf@root> <osgi:echo a b>
a b
karaf@root> <<osgi:echo a b>>
a b
karaf@root> <<bundle 0> tostring>
org.apache.felix.framework [0]
However, the $() approach works fine too and so I'm happy to support this,
so we can get this issue resolved.
I have tested the latest FELIX-1471.patch and it mostly works OK:
> echo aa; (echo ab; echo ac | grep -n a | tac)
aa
1 ab 3 ac
but fails when the result of () is in an assignment:
karaf@root> x = (echo aa; (echo ab; echo ac | grep -n a | tac))
org.osgi.framework.InvalidSyntaxException: expected value|substring
at org.apache.felix.framework.FilterImpl.<init>(FilterImpl.java:81)
at org.apache.felix.framework.Felix.getServiceReferences(Felix.java:2893)
Derek
2009/8/18 Guillaume Nodet <gn...@gmail.com>
>
> On Tue, Aug 18, 2009 at 09:17, Derek Baum <de...@paremus.com> wrote:
>
> > 2009/8/17 Guillaume Nodet <gn...@gmail.com>
> >
> > >
> > > So in short, the patch does the following:
> > > * replace <> with $()
> > > * use ( ) for grouping commands when on the edge of the command
> > > * make the number of evaluation predictable
> > > * have a syntax and semantic which is mostly (fully) in sync with bash
> > > * re-evaluate / split expanded arguments that are not quoted
> >
> >
> >
> > I can still see no reason for having () and $() as two separate operators.
> > This unncessarily compllicates syntax without adding any new capability.
> >
> > You previously gave the following example to demonstrate the need for a
> > separate grouping operator:
> >
> > >The grouping operator is imho needed to be able to order pipes and
> > columns:
> > > (echo a ; echo b) | tac
> > > echo a ; (echo b | tac)
> >
> > However, this example works fine with the existing <> execution quotes:
> >
> > karaf@root> <echo a; echo b> | tac
> > ab
> > karaf@root> echo a; <echo b | tac>
> > a
> > b
> >
> > Do you have any other example or use case that demonstrates the need for a
> > separate grouping operator?
> >
> > () in bash is NOT only used for grouping - it executes the command within
> > (), just like the existing <>.
> > $() in bash executes and captures stdout into a string - equivalent to
> > <command args | tac> in gogo.
> >
>
> Well the key difference between those operators in bash is the number of
> times the evaluation happen.
>
> ( ) does not change the number of times a command will be evaluated, that's
> why i call it grouping.
> What i mean is that if you remove the ( ), the commands will be executed the
> same number of time.
> echo a => echo a
> ( echo a ) => echo a
> ( ( echo a ) ) => echo a
> All of those will produce the same result.
>
> $( ) will increment the number of evaluation each time it's used, and is
> therefore not idemptotent.
> echo echo echo a => echo echo a
> $(echo echo echo a) => echo a
> $( $( echo echo echo a) ) => a
>
> I don't really see how we can conflate both operators using < > or any other
> syntax.
> With the current state of gogo, you're not really sure how many times
> evaluation will happen.
>
>
> >
> > To try to understand the need for separate () and $() operators, I have
> > taken the gogo TestParser.java from the FELIX-1471.patch and replaced both
> > $() and () with <>. I then ran the test against the unpatched code.
> >
> > All tests worked except some newly added tests within
> > testGroupingAndEvaluation() like:
> >
> > assertEquals("a", c.execute("<echo echo a>") + "");
> >
> > This fails because <echo echo a> evaluates to the String "echo a", which is
> > then evaluated as a command and the command 'echo a' is not found.
> >
> > assertEquals("a", c.execute("$(echo echo a)") + "");
> >
> > This works because of the complex re-parsing done by $() that you describe
> > below.
>
>
> Right, and I think this reparsing of arguments should be done anyway. So
> maybe we need a separate jira for that one.
>
> I think I understood where our uncomprehension comes from. I first started
> to have a look at FELIX-1325 (throwing an exception when the can't be found,
> even if it has no arguments). The problem is that all those issues are
> linked.
> What you describe above works only because when you have a single token on
> the command line and that no command is found, the token is simply returned.
> This means that in all the above examples, the number of evaluation is not
> really important, because executing "a" will return "a".
> This hides some real issues imho, as the following tests, that all pass on
> trunk show:
>
> assertEquals("echo echo", c.execute("echo echo echo"));
> assertEquals("echo", c.execute("<echo echo echo>"));
> assertEquals("", c.execute("<<echo echo echo>>"));
>
> assertEquals("echo a", c.execute("echo echo a"));
> assertEquals("a", c.execute("<echo echo a>"));
> assertEquals("a", c.execute("<<echo echo a>>"));
>
>
> So the behavior of < > is that it run the command(s) inside it *and*
> evaluates it. It's not only grouping.
>
> Now, let's take an example:
>
> assertEquals("a", c.execute("echoout \"a\nb\" | grep a | capture"));
> assertEquals("b", c.execute("echoout \"a\nb\" | grep b | capture"));
> assertEquals("ab", c.execute("<echoout \"a\nb\" | grep a | capture>
> ; <echoout \"a\nb\" | grep b | capture> | capture"));
>
> assertEquals("", c.execute("<echoout \"echo\ngrep\" | grep echo |
> capture> ; <echoout \"echo\ngrep\" | grep grep | capture> | capture"));
>
> The first two tests are ok. The third test is equivalent to "test1 ; test2
> | capture".
> Remember that atm ';' takes precedence over '|'.
>
> Now the last test is the same as the third one, but with different values.
> The output should be "echogrep", but isn't, due to the additional
> evaluation.
> The third test would also fail if we apply FELIX-1325 afaik.
>
>
> >
> > In bash, if you need to re-parse some text, you use the 'eval' command:
> >
> > $ eval $(echo echo '$HOME')
> > /Users/derek
> >
> > We could take exactly the same approach in gogo, by adding a simple eval
> > command for use on the rare occassions when it is required.
> >
> > Derek
> >
> >
> >
> > >
> > >
> > > I'm happy to discuss things further, but the major problem is related to
> > > make the evaluation predictable, which sounds easy, but is not really ...
> > > And this require to re-evaluate / split the expanded arguments.
> > > See the following example:
> > > assertEquals("a", c.execute("$($(echo echo echo a)) | capture"));
> > > The "echo echo echo a" command is executed and prints "echo echo a". This
> > > result is inside $() so it has to be interpreted as a full command line,
> > > not
> > > as a single argument which would be a string "echo echo a" as this would
> > > return a command not found.
> > >
> > >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Aug 19, 2009 at 18:56, Derek Baum <de...@paremus.com> wrote:
> Many of the current tests use <> when it is not needed, so the problem
> with extra evaluations could be removed by improving the tests.
>
> As the use of <> is not the intent of the test, it should be written
> without <>
>
> assertEquals("ca b", c.execute("e = { echo c$args } ; e a b | capture"));
>
Right, those tests are wrong. I think i just forgot that the inverted
priority wrt bash when I wrote those tests.
>
> Derek
>
> 2009/8/18 Guillaume Nodet <gn...@gmail.com>:
> > Another example taken from the existing test suite:
> >
> > assertEquals("ca b", c.execute("e = { echo c$args } ; <e a b |
> > capture>"));
> >
> > This test currently works fine.
> >
> > When extracting the patch for FELIX-1498, this one and the two following
> > ones are the only one to fail.
> > The reason is again caused by the fact that a single argument won't cause
> > any exception if it's not a command.
> > This wasn't a problem because "ca b" is simply returned, but by splitting
> > it, it becomes more evident that the result is evaluated, which is not
> the
> > intent of the test.
> >
> > On Tue, Aug 18, 2009 at 16:46, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> >>
> >>
> >> On Tue, Aug 18, 2009 at 09:17, Derek Baum <de...@paremus.com>
> wrote:
> >>
> >>> 2009/8/17 Guillaume Nodet <gn...@gmail.com>
> >>>
> >>> >
> >>> > So in short, the patch does the following:
> >>> > * replace <> with $()
> >>> > * use ( ) for grouping commands when on the edge of the command
> >>> > * make the number of evaluation predictable
> >>> > * have a syntax and semantic which is mostly (fully) in sync with
> bash
> >>> > * re-evaluate / split expanded arguments that are not quoted
> >>>
> >>>
> >>>
> >>> I can still see no reason for having () and $() as two separate
> operators.
> >>> This unncessarily compllicates syntax without adding any new
> capability.
> >>>
> >>> You previously gave the following example to demonstrate the need for a
> >>> separate grouping operator:
> >>>
> >>> >The grouping operator is imho needed to be able to order pipes and
> >>> columns:
> >>> > (echo a ; echo b) | tac
> >>> > echo a ; (echo b | tac)
> >>>
> >>> However, this example works fine with the existing <> execution quotes:
> >>>
> >>> karaf@root> <echo a; echo b> | tac
> >>> ab
> >>> karaf@root> echo a; <echo b | tac>
> >>> a
> >>> b
> >>>
> >>> Do you have any other example or use case that demonstrates the need
> for a
> >>> separate grouping operator?
> >>>
> >>> () in bash is NOT only used for grouping - it executes the command
> within
> >>> (), just like the existing <>.
> >>> $() in bash executes and captures stdout into a string - equivalent to
> >>> <command args | tac> in gogo.
> >>>
> >>
> >> Well the key difference between those operators in bash is the number of
> >> times the evaluation happen.
> >>
> >> ( ) does not change the number of times a command will be evaluated,
> that's
> >> why i call it grouping.
> >> What i mean is that if you remove the ( ), the commands will be executed
> >> the same number of time.
> >> echo a => echo a
> >> ( echo a ) => echo a
> >> ( ( echo a ) ) => echo a
> >> All of those will produce the same result.
> >>
> >> $( ) will increment the number of evaluation each time it's used, and is
> >> therefore not idemptotent.
> >> echo echo echo a => echo echo a
> >> $(echo echo echo a) => echo a
> >> $( $( echo echo echo a) ) => a
> >>
> >> I don't really see how we can conflate both operators using < > or any
> >> other syntax.
> >> With the current state of gogo, you're not really sure how many times
> >> evaluation will happen.
> >>
> >>
> >>>
> >>> To try to understand the need for separate () and $() operators, I have
> >>> taken the gogo TestParser.java from the FELIX-1471.patch and replaced
> both
> >>> $() and () with <>. I then ran the test against the unpatched code.
> >>>
> >>> All tests worked except some newly added tests within
> >>> testGroupingAndEvaluation() like:
> >>>
> >>> assertEquals("a", c.execute("<echo echo a>") + "");
> >>>
> >>> This fails because <echo echo a> evaluates to the String "echo a",
> which
> >>> is
> >>> then evaluated as a command and the command 'echo a' is not found.
> >>>
> >>> assertEquals("a", c.execute("$(echo echo a)") + "");
> >>>
> >>> This works because of the complex re-parsing done by $() that you
> describe
> >>> below.
> >>
> >>
> >> Right, and I think this reparsing of arguments should be done anyway.
> So
> >> maybe we need a separate jira for that one.
> >>
> >> I think I understood where our uncomprehension comes from. I first
> started
> >> to have a look at FELIX-1325 (throwing an exception when the can't be
> found,
> >> even if it has no arguments). The problem is that all those issues are
> >> linked.
> >> What you describe above works only because when you have a single token
> on
> >> the command line and that no command is found, the token is simply
> returned.
> >> This means that in all the above examples, the number of evaluation is
> not
> >> really important, because executing "a" will return "a".
> >> This hides some real issues imho, as the following tests, that all pass
> on
> >> trunk show:
> >>
> >> assertEquals("echo echo", c.execute("echo echo echo"));
> >> assertEquals("echo", c.execute("<echo echo echo>"));
> >> assertEquals("", c.execute("<<echo echo echo>>"));
> >>
> >> assertEquals("echo a", c.execute("echo echo a"));
> >> assertEquals("a", c.execute("<echo echo a>"));
> >> assertEquals("a", c.execute("<<echo echo a>>"));
> >>
> >>
> >> So the behavior of < > is that it run the command(s) inside it *and*
> >> evaluates it. It's not only grouping.
> >>
> >> Now, let's take an example:
> >>
> >> assertEquals("a", c.execute("echoout \"a\nb\" | grep a |
> >> capture"));
> >> assertEquals("b", c.execute("echoout \"a\nb\" | grep b |
> >> capture"));
> >> assertEquals("ab", c.execute("<echoout \"a\nb\" | grep a |
> capture>
> >> ; <echoout \"a\nb\" | grep b | capture> | capture"));
> >>
> >> assertEquals("", c.execute("<echoout \"echo\ngrep\" | grep echo
> |
> >> capture> ; <echoout \"echo\ngrep\" | grep grep | capture> | capture"));
> >>
> >> The first two tests are ok. The third test is equivalent to "test1 ;
> test2
> >> | capture".
> >> Remember that atm ';' takes precedence over '|'.
> >>
> >> Now the last test is the same as the third one, but with different
> values.
> >> The output should be "echogrep", but isn't, due to the additional
> >> evaluation.
> >> The third test would also fail if we apply FELIX-1325 afaik.
> >>
> >>
> >>>
> >>> In bash, if you need to re-parse some text, you use the 'eval' command:
> >>>
> >>> $ eval $(echo echo '$HOME')
> >>> /Users/derek
> >>>
> >>> We could take exactly the same approach in gogo, by adding a simple
> eval
> >>> command for use on the rare occassions when it is required.
> >>>
> >>> Derek
> >>>
> >>>
> >>>
> >>> >
> >>> >
> >>> > I'm happy to discuss things further, but the major problem is related
> to
> >>> > make the evaluation predictable, which sounds easy, but is not really
> >>> ...
> >>> > And this require to re-evaluate / split the expanded arguments.
> >>> > See the following example:
> >>> > assertEquals("a", c.execute("$($(echo echo echo a)) |
> capture"));
> >>> > The "echo echo echo a" command is executed and prints "echo echo a".
> >>> This
> >>> > result is inside $() so it has to be interpreted as a full command
> line,
> >>> > not
> >>> > as a single argument which would be a string "echo echo a" as this
> would
> >>> > return a command not found.
> >>> >
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> 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
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
Many of the current tests use <> when it is not needed, so the problem
with extra evaluations could be removed by improving the tests.
As the use of <> is not the intent of the test, it should be written without <>
assertEquals("ca b", c.execute("e = { echo c$args } ; e a b | capture"));
Derek
2009/8/18 Guillaume Nodet <gn...@gmail.com>:
> Another example taken from the existing test suite:
>
> assertEquals("ca b", c.execute("e = { echo c$args } ; <e a b |
> capture>"));
>
> This test currently works fine.
>
> When extracting the patch for FELIX-1498, this one and the two following
> ones are the only one to fail.
> The reason is again caused by the fact that a single argument won't cause
> any exception if it's not a command.
> This wasn't a problem because "ca b" is simply returned, but by splitting
> it, it becomes more evident that the result is evaluated, which is not the
> intent of the test.
>
> On Tue, Aug 18, 2009 at 16:46, Guillaume Nodet <gn...@gmail.com> wrote:
>
>>
>>
>> On Tue, Aug 18, 2009 at 09:17, Derek Baum <de...@paremus.com> wrote:
>>
>>> 2009/8/17 Guillaume Nodet <gn...@gmail.com>
>>>
>>> >
>>> > So in short, the patch does the following:
>>> > * replace <> with $()
>>> > * use ( ) for grouping commands when on the edge of the command
>>> > * make the number of evaluation predictable
>>> > * have a syntax and semantic which is mostly (fully) in sync with bash
>>> > * re-evaluate / split expanded arguments that are not quoted
>>>
>>>
>>>
>>> I can still see no reason for having () and $() as two separate operators.
>>> This unncessarily compllicates syntax without adding any new capability.
>>>
>>> You previously gave the following example to demonstrate the need for a
>>> separate grouping operator:
>>>
>>> >The grouping operator is imho needed to be able to order pipes and
>>> columns:
>>> > (echo a ; echo b) | tac
>>> > echo a ; (echo b | tac)
>>>
>>> However, this example works fine with the existing <> execution quotes:
>>>
>>> karaf@root> <echo a; echo b> | tac
>>> ab
>>> karaf@root> echo a; <echo b | tac>
>>> a
>>> b
>>>
>>> Do you have any other example or use case that demonstrates the need for a
>>> separate grouping operator?
>>>
>>> () in bash is NOT only used for grouping - it executes the command within
>>> (), just like the existing <>.
>>> $() in bash executes and captures stdout into a string - equivalent to
>>> <command args | tac> in gogo.
>>>
>>
>> Well the key difference between those operators in bash is the number of
>> times the evaluation happen.
>>
>> ( ) does not change the number of times a command will be evaluated, that's
>> why i call it grouping.
>> What i mean is that if you remove the ( ), the commands will be executed
>> the same number of time.
>> echo a => echo a
>> ( echo a ) => echo a
>> ( ( echo a ) ) => echo a
>> All of those will produce the same result.
>>
>> $( ) will increment the number of evaluation each time it's used, and is
>> therefore not idemptotent.
>> echo echo echo a => echo echo a
>> $(echo echo echo a) => echo a
>> $( $( echo echo echo a) ) => a
>>
>> I don't really see how we can conflate both operators using < > or any
>> other syntax.
>> With the current state of gogo, you're not really sure how many times
>> evaluation will happen.
>>
>>
>>>
>>> To try to understand the need for separate () and $() operators, I have
>>> taken the gogo TestParser.java from the FELIX-1471.patch and replaced both
>>> $() and () with <>. I then ran the test against the unpatched code.
>>>
>>> All tests worked except some newly added tests within
>>> testGroupingAndEvaluation() like:
>>>
>>> assertEquals("a", c.execute("<echo echo a>") + "");
>>>
>>> This fails because <echo echo a> evaluates to the String "echo a", which
>>> is
>>> then evaluated as a command and the command 'echo a' is not found.
>>>
>>> assertEquals("a", c.execute("$(echo echo a)") + "");
>>>
>>> This works because of the complex re-parsing done by $() that you describe
>>> below.
>>
>>
>> Right, and I think this reparsing of arguments should be done anyway. So
>> maybe we need a separate jira for that one.
>>
>> I think I understood where our uncomprehension comes from. I first started
>> to have a look at FELIX-1325 (throwing an exception when the can't be found,
>> even if it has no arguments). The problem is that all those issues are
>> linked.
>> What you describe above works only because when you have a single token on
>> the command line and that no command is found, the token is simply returned.
>> This means that in all the above examples, the number of evaluation is not
>> really important, because executing "a" will return "a".
>> This hides some real issues imho, as the following tests, that all pass on
>> trunk show:
>>
>> assertEquals("echo echo", c.execute("echo echo echo"));
>> assertEquals("echo", c.execute("<echo echo echo>"));
>> assertEquals("", c.execute("<<echo echo echo>>"));
>>
>> assertEquals("echo a", c.execute("echo echo a"));
>> assertEquals("a", c.execute("<echo echo a>"));
>> assertEquals("a", c.execute("<<echo echo a>>"));
>>
>>
>> So the behavior of < > is that it run the command(s) inside it *and*
>> evaluates it. It's not only grouping.
>>
>> Now, let's take an example:
>>
>> assertEquals("a", c.execute("echoout \"a\nb\" | grep a |
>> capture"));
>> assertEquals("b", c.execute("echoout \"a\nb\" | grep b |
>> capture"));
>> assertEquals("ab", c.execute("<echoout \"a\nb\" | grep a | capture>
>> ; <echoout \"a\nb\" | grep b | capture> | capture"));
>>
>> assertEquals("", c.execute("<echoout \"echo\ngrep\" | grep echo |
>> capture> ; <echoout \"echo\ngrep\" | grep grep | capture> | capture"));
>>
>> The first two tests are ok. The third test is equivalent to "test1 ; test2
>> | capture".
>> Remember that atm ';' takes precedence over '|'.
>>
>> Now the last test is the same as the third one, but with different values.
>> The output should be "echogrep", but isn't, due to the additional
>> evaluation.
>> The third test would also fail if we apply FELIX-1325 afaik.
>>
>>
>>>
>>> In bash, if you need to re-parse some text, you use the 'eval' command:
>>>
>>> $ eval $(echo echo '$HOME')
>>> /Users/derek
>>>
>>> We could take exactly the same approach in gogo, by adding a simple eval
>>> command for use on the rare occassions when it is required.
>>>
>>> Derek
>>>
>>>
>>>
>>> >
>>> >
>>> > I'm happy to discuss things further, but the major problem is related to
>>> > make the evaluation predictable, which sounds easy, but is not really
>>> ...
>>> > And this require to re-evaluate / split the expanded arguments.
>>> > See the following example:
>>> > assertEquals("a", c.execute("$($(echo echo echo a)) | capture"));
>>> > The "echo echo echo a" command is executed and prints "echo echo a".
>>> This
>>> > result is inside $() so it has to be interpreted as a full command line,
>>> > not
>>> > as a single argument which would be a string "echo echo a" as this would
>>> > return a command not found.
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> 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
>
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
Another example taken from the existing test suite:
assertEquals("ca b", c.execute("e = { echo c$args } ; <e a b |
capture>"));
This test currently works fine.
When extracting the patch for FELIX-1498, this one and the two following
ones are the only one to fail.
The reason is again caused by the fact that a single argument won't cause
any exception if it's not a command.
This wasn't a problem because "ca b" is simply returned, but by splitting
it, it becomes more evident that the result is evaluated, which is not the
intent of the test.
On Tue, Aug 18, 2009 at 16:46, Guillaume Nodet <gn...@gmail.com> wrote:
>
>
> On Tue, Aug 18, 2009 at 09:17, Derek Baum <de...@paremus.com> wrote:
>
>> 2009/8/17 Guillaume Nodet <gn...@gmail.com>
>>
>> >
>> > So in short, the patch does the following:
>> > * replace <> with $()
>> > * use ( ) for grouping commands when on the edge of the command
>> > * make the number of evaluation predictable
>> > * have a syntax and semantic which is mostly (fully) in sync with bash
>> > * re-evaluate / split expanded arguments that are not quoted
>>
>>
>>
>> I can still see no reason for having () and $() as two separate operators.
>> This unncessarily compllicates syntax without adding any new capability.
>>
>> You previously gave the following example to demonstrate the need for a
>> separate grouping operator:
>>
>> >The grouping operator is imho needed to be able to order pipes and
>> columns:
>> > (echo a ; echo b) | tac
>> > echo a ; (echo b | tac)
>>
>> However, this example works fine with the existing <> execution quotes:
>>
>> karaf@root> <echo a; echo b> | tac
>> ab
>> karaf@root> echo a; <echo b | tac>
>> a
>> b
>>
>> Do you have any other example or use case that demonstrates the need for a
>> separate grouping operator?
>>
>> () in bash is NOT only used for grouping - it executes the command within
>> (), just like the existing <>.
>> $() in bash executes and captures stdout into a string - equivalent to
>> <command args | tac> in gogo.
>>
>
> Well the key difference between those operators in bash is the number of
> times the evaluation happen.
>
> ( ) does not change the number of times a command will be evaluated, that's
> why i call it grouping.
> What i mean is that if you remove the ( ), the commands will be executed
> the same number of time.
> echo a => echo a
> ( echo a ) => echo a
> ( ( echo a ) ) => echo a
> All of those will produce the same result.
>
> $( ) will increment the number of evaluation each time it's used, and is
> therefore not idemptotent.
> echo echo echo a => echo echo a
> $(echo echo echo a) => echo a
> $( $( echo echo echo a) ) => a
>
> I don't really see how we can conflate both operators using < > or any
> other syntax.
> With the current state of gogo, you're not really sure how many times
> evaluation will happen.
>
>
>>
>> To try to understand the need for separate () and $() operators, I have
>> taken the gogo TestParser.java from the FELIX-1471.patch and replaced both
>> $() and () with <>. I then ran the test against the unpatched code.
>>
>> All tests worked except some newly added tests within
>> testGroupingAndEvaluation() like:
>>
>> assertEquals("a", c.execute("<echo echo a>") + "");
>>
>> This fails because <echo echo a> evaluates to the String "echo a", which
>> is
>> then evaluated as a command and the command 'echo a' is not found.
>>
>> assertEquals("a", c.execute("$(echo echo a)") + "");
>>
>> This works because of the complex re-parsing done by $() that you describe
>> below.
>
>
> Right, and I think this reparsing of arguments should be done anyway. So
> maybe we need a separate jira for that one.
>
> I think I understood where our uncomprehension comes from. I first started
> to have a look at FELIX-1325 (throwing an exception when the can't be found,
> even if it has no arguments). The problem is that all those issues are
> linked.
> What you describe above works only because when you have a single token on
> the command line and that no command is found, the token is simply returned.
> This means that in all the above examples, the number of evaluation is not
> really important, because executing "a" will return "a".
> This hides some real issues imho, as the following tests, that all pass on
> trunk show:
>
> assertEquals("echo echo", c.execute("echo echo echo"));
> assertEquals("echo", c.execute("<echo echo echo>"));
> assertEquals("", c.execute("<<echo echo echo>>"));
>
> assertEquals("echo a", c.execute("echo echo a"));
> assertEquals("a", c.execute("<echo echo a>"));
> assertEquals("a", c.execute("<<echo echo a>>"));
>
>
> So the behavior of < > is that it run the command(s) inside it *and*
> evaluates it. It's not only grouping.
>
> Now, let's take an example:
>
> assertEquals("a", c.execute("echoout \"a\nb\" | grep a |
> capture"));
> assertEquals("b", c.execute("echoout \"a\nb\" | grep b |
> capture"));
> assertEquals("ab", c.execute("<echoout \"a\nb\" | grep a | capture>
> ; <echoout \"a\nb\" | grep b | capture> | capture"));
>
> assertEquals("", c.execute("<echoout \"echo\ngrep\" | grep echo |
> capture> ; <echoout \"echo\ngrep\" | grep grep | capture> | capture"));
>
> The first two tests are ok. The third test is equivalent to "test1 ; test2
> | capture".
> Remember that atm ';' takes precedence over '|'.
>
> Now the last test is the same as the third one, but with different values.
> The output should be "echogrep", but isn't, due to the additional
> evaluation.
> The third test would also fail if we apply FELIX-1325 afaik.
>
>
>>
>> In bash, if you need to re-parse some text, you use the 'eval' command:
>>
>> $ eval $(echo echo '$HOME')
>> /Users/derek
>>
>> We could take exactly the same approach in gogo, by adding a simple eval
>> command for use on the rare occassions when it is required.
>>
>> Derek
>>
>>
>>
>> >
>> >
>> > I'm happy to discuss things further, but the major problem is related to
>> > make the evaluation predictable, which sounds easy, but is not really
>> ...
>> > And this require to re-evaluate / split the expanded arguments.
>> > See the following example:
>> > assertEquals("a", c.execute("$($(echo echo echo a)) | capture"));
>> > The "echo echo echo a" command is executed and prints "echo echo a".
>> This
>> > result is inside $() so it has to be interpreted as a full command line,
>> > not
>> > as a single argument which would be a string "echo echo a" as this would
>> > return a command not found.
>> >
>> >
>>
>
>
>
> --
> 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
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Aug 18, 2009 at 09:17, Derek Baum <de...@paremus.com> wrote:
> 2009/8/17 Guillaume Nodet <gn...@gmail.com>
>
> >
> > So in short, the patch does the following:
> > * replace <> with $()
> > * use ( ) for grouping commands when on the edge of the command
> > * make the number of evaluation predictable
> > * have a syntax and semantic which is mostly (fully) in sync with bash
> > * re-evaluate / split expanded arguments that are not quoted
>
>
>
> I can still see no reason for having () and $() as two separate operators.
> This unncessarily compllicates syntax without adding any new capability.
>
> You previously gave the following example to demonstrate the need for a
> separate grouping operator:
>
> >The grouping operator is imho needed to be able to order pipes and
> columns:
> > (echo a ; echo b) | tac
> > echo a ; (echo b | tac)
>
> However, this example works fine with the existing <> execution quotes:
>
> karaf@root> <echo a; echo b> | tac
> ab
> karaf@root> echo a; <echo b | tac>
> a
> b
>
> Do you have any other example or use case that demonstrates the need for a
> separate grouping operator?
>
> () in bash is NOT only used for grouping - it executes the command within
> (), just like the existing <>.
> $() in bash executes and captures stdout into a string - equivalent to
> <command args | tac> in gogo.
>
Well the key difference between those operators in bash is the number of
times the evaluation happen.
( ) does not change the number of times a command will be evaluated, that's
why i call it grouping.
What i mean is that if you remove the ( ), the commands will be executed the
same number of time.
echo a => echo a
( echo a ) => echo a
( ( echo a ) ) => echo a
All of those will produce the same result.
$( ) will increment the number of evaluation each time it's used, and is
therefore not idemptotent.
echo echo echo a => echo echo a
$(echo echo echo a) => echo a
$( $( echo echo echo a) ) => a
I don't really see how we can conflate both operators using < > or any other
syntax.
With the current state of gogo, you're not really sure how many times
evaluation will happen.
>
> To try to understand the need for separate () and $() operators, I have
> taken the gogo TestParser.java from the FELIX-1471.patch and replaced both
> $() and () with <>. I then ran the test against the unpatched code.
>
> All tests worked except some newly added tests within
> testGroupingAndEvaluation() like:
>
> assertEquals("a", c.execute("<echo echo a>") + "");
>
> This fails because <echo echo a> evaluates to the String "echo a", which is
> then evaluated as a command and the command 'echo a' is not found.
>
> assertEquals("a", c.execute("$(echo echo a)") + "");
>
> This works because of the complex re-parsing done by $() that you describe
> below.
Right, and I think this reparsing of arguments should be done anyway. So
maybe we need a separate jira for that one.
I think I understood where our uncomprehension comes from. I first started
to have a look at FELIX-1325 (throwing an exception when the can't be found,
even if it has no arguments). The problem is that all those issues are
linked.
What you describe above works only because when you have a single token on
the command line and that no command is found, the token is simply returned.
This means that in all the above examples, the number of evaluation is not
really important, because executing "a" will return "a".
This hides some real issues imho, as the following tests, that all pass on
trunk show:
assertEquals("echo echo", c.execute("echo echo echo"));
assertEquals("echo", c.execute("<echo echo echo>"));
assertEquals("", c.execute("<<echo echo echo>>"));
assertEquals("echo a", c.execute("echo echo a"));
assertEquals("a", c.execute("<echo echo a>"));
assertEquals("a", c.execute("<<echo echo a>>"));
So the behavior of < > is that it run the command(s) inside it *and*
evaluates it. It's not only grouping.
Now, let's take an example:
assertEquals("a", c.execute("echoout \"a\nb\" | grep a | capture"));
assertEquals("b", c.execute("echoout \"a\nb\" | grep b | capture"));
assertEquals("ab", c.execute("<echoout \"a\nb\" | grep a | capture>
; <echoout \"a\nb\" | grep b | capture> | capture"));
assertEquals("", c.execute("<echoout \"echo\ngrep\" | grep echo |
capture> ; <echoout \"echo\ngrep\" | grep grep | capture> | capture"));
The first two tests are ok. The third test is equivalent to "test1 ; test2
| capture".
Remember that atm ';' takes precedence over '|'.
Now the last test is the same as the third one, but with different values.
The output should be "echogrep", but isn't, due to the additional
evaluation.
The third test would also fail if we apply FELIX-1325 afaik.
>
> In bash, if you need to re-parse some text, you use the 'eval' command:
>
> $ eval $(echo echo '$HOME')
> /Users/derek
>
> We could take exactly the same approach in gogo, by adding a simple eval
> command for use on the rare occassions when it is required.
>
> Derek
>
>
>
> >
> >
> > I'm happy to discuss things further, but the major problem is related to
> > make the evaluation predictable, which sounds easy, but is not really ...
> > And this require to re-evaluate / split the expanded arguments.
> > See the following example:
> > assertEquals("a", c.execute("$($(echo echo echo a)) | capture"));
> > The "echo echo echo a" command is executed and prints "echo echo a". This
> > result is inside $() so it has to be interpreted as a full command line,
> > not
> > as a single argument which would be a string "echo echo a" as this would
> > return a command not found.
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
2009/8/17 Guillaume Nodet <gn...@gmail.com>
>
> So in short, the patch does the following:
> * replace <> with $()
> * use ( ) for grouping commands when on the edge of the command
> * make the number of evaluation predictable
> * have a syntax and semantic which is mostly (fully) in sync with bash
> * re-evaluate / split expanded arguments that are not quoted
I can still see no reason for having () and $() as two separate operators.
This unncessarily compllicates syntax without adding any new capability.
You previously gave the following example to demonstrate the need for a
separate grouping operator:
>The grouping operator is imho needed to be able to order pipes and columns:
> (echo a ; echo b) | tac
> echo a ; (echo b | tac)
However, this example works fine with the existing <> execution quotes:
karaf@root> <echo a; echo b> | tac
ab
karaf@root> echo a; <echo b | tac>
a
b
Do you have any other example or use case that demonstrates the need for a
separate grouping operator?
() in bash is NOT only used for grouping - it executes the command within
(), just like the existing <>.
$() in bash executes and captures stdout into a string - equivalent to
<command args | tac> in gogo.
To try to understand the need for separate () and $() operators, I have
taken the gogo TestParser.java from the FELIX-1471.patch and replaced both
$() and () with <>. I then ran the test against the unpatched code.
All tests worked except some newly added tests within
testGroupingAndEvaluation() like:
assertEquals("a", c.execute("<echo echo a>") + "");
This fails because <echo echo a> evaluates to the String "echo a", which is
then evaluated as a command and the command 'echo a' is not found.
assertEquals("a", c.execute("$(echo echo a)") + "");
This works because of the complex re-parsing done by $() that you describe
below.
In bash, if you need to re-parse some text, you use the 'eval' command:
$ eval $(echo echo '$HOME')
/Users/derek
We could take exactly the same approach in gogo, by adding a simple eval
command for use on the rare occassions when it is required.
Derek
>
>
> I'm happy to discuss things further, but the major problem is related to
> make the evaluation predictable, which sounds easy, but is not really ...
> And this require to re-evaluate / split the expanded arguments.
> See the following example:
> assertEquals("a", c.execute("$($(echo echo echo a)) | capture"));
> The "echo echo echo a" command is executed and prints "echo echo a". This
> result is inside $() so it has to be interpreted as a full command line,
> not
> as a single argument which would be a string "echo echo a" as this would
> return a command not found.
>
>
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
On Sun, Aug 16, 2009 at 13:30, Derek Baum <de...@paremus.com> wrote:
> I've applied the FELIX-1471 patch to Karaf and get an exception when using
> assignment with grouping:
>
>
> karaf@root> x = (echo a; echo b)
> org.osgi.framework.InvalidSyntaxException: expected value|substring
> at org.apache.felix.framework.FilterImpl.<init>(FilterImpl.java:81)
>
> In RFC132 parens () were used to create an LDAP filter - it looks like it's
> still trying to do that in an assignment.
>
>
> Using $() works OK:
>
> karaf@root> x = $(echo a; echo b)
> a
> b
>
> But if () are supposed to be used for grouping, then I shouldn't need to
> use
> $()?
>
What I did is that i based my patch on the way bash work, mostly to try to
understand some edge cases with $().
Most of those are captured in the test named testGroupingAndEvaluation() in
TestParser.
So, ( ) only work for *grouping* commands. But in the example above, what
you expect is x to be assigned to the value of the execution of "echo a;
echo b". So this is not really grouping, but more evaluation. So it sounds
logical to me to use the $( ) construction instead.
In addition, the grouping operator is mostly used to change the priority
between ';' and '|', so the parentheses can really only appear at the edges
of the command. Also, ( ) does not change the result of the execution, so
that we have:
assertEquals("echo a", c.execute("echo echo a | capture"));
assertEquals("echo a", c.execute("(echo echo a) | capture"));
assertEquals("echo a", c.execute("((echo echo a)) | capture"));
assertEquals("echo a", c.execute("(((echo echo a))) | capture"));
What you see is the result of the parser not throwing exceptions when
parentheses are not at the edge of the command, so that those parentheses
are not managed. That's why the ldap filter construction kicks in, and
that's also why the tests using grep and () don't have to change:
assertEquals("def", c.execute("echo def|grep (d.*)|capture"));
(actually, my patch seems to change those test, but i'll upload a new one
without those modifications, and the test still succeed without any other
changes).
So in short, the patch does the following:
* replace <> with $()
* use ( ) for grouping commands when on the edge of the command
* make the number of evaluation predictable
* have a syntax and semantic which is mostly (fully) in sync with bash
* re-evaluate / split expanded arguments that are not quoted
I'm happy to discuss things further, but the major problem is related to
make the evaluation predictable, which sounds easy, but is not really ...
And this require to re-evaluate / split the expanded arguments.
See the following example:
assertEquals("a", c.execute("$($(echo echo echo a)) | capture"));
The "echo echo echo a" command is executed and prints "echo echo a". This
result is inside $() so it has to be interpreted as a full command line, not
as a single argument which would be a string "echo echo a" as this would
return a command not found.
>
>
> Is the FELIX-1325 patch dependent on the FELIX-1471 patch?
I think so. I've created the latest patch attached on top of FELIX-1471.
The previous one was not, but lead to problems and inconsistencies that
FELIX-1471 fixed.
>
>
> I also noticed that shell:echo doesn't print a space between its last two
> arguments:
>
> karaf@root> shell:echo 1 2 3 4 5
> 1 2 3 45
>
Fixed. Thx for reporting.
>
> Derek
>
>
>
>
>
> 2009/8/16 Guillaume Nodet <gn...@gmail.com>
>
> > I've attached 2 patches to FELIX-1471 and FELIX-1325 to fix those issues.
> > Ftr, those are:
> > * use () for command grouping and $() for evaluation
> > * throw an exception when a command is not found, even if it has no
> > arguments
> >
> > Feedback welcome.
> >
> > On Wed, Aug 12, 2009 at 21:06, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > > I'll try to come up with a patch for further discussion.
> > > I think the grouping operator (...) will be handled directly by the
> > parser
> > > without surfacing to the closure and pipes interpreters, while the
> $(...)
> > > for evaluation would be handled by those the way <...> currently works.
> > >
> > >
> > > On Wed, Aug 12, 2009 at 15:37, Richard S. Hall <heavy@ungoverned.org
> > >wrote:
> > >
> > >> On 8/12/09 4:00, Guillaume Nodet wrote:
> > >>
> > >>> So I'd rather have ( ... ) for pure grouping and $( ... ) for
> > evaluating
> > >>> as
> > >>> we have in bash.
> > >>>
> > >>>
> > >>>
> > >>
> > >> That seems reasonable to me.
> > >>
> > >> -> richard
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > 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
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
I've applied the FELIX-1471 patch to Karaf and get an exception when using
assignment with grouping:
karaf@root> x = (echo a; echo b)
org.osgi.framework.InvalidSyntaxException: expected value|substring
at org.apache.felix.framework.FilterImpl.<init>(FilterImpl.java:81)
In RFC132 parens () were used to create an LDAP filter - it looks like it's
still trying to do that in an assignment.
Using $() works OK:
karaf@root> x = $(echo a; echo b)
a
b
But if () are supposed to be used for grouping, then I shouldn't need to use
$()?
Is the FELIX-1325 patch dependent on the FELIX-1471 patch?
I also noticed that shell:echo doesn't print a space between its last two
arguments:
karaf@root> shell:echo 1 2 3 4 5
1 2 3 45
Derek
2009/8/16 Guillaume Nodet <gn...@gmail.com>
> I've attached 2 patches to FELIX-1471 and FELIX-1325 to fix those issues.
> Ftr, those are:
> * use () for command grouping and $() for evaluation
> * throw an exception when a command is not found, even if it has no
> arguments
>
> Feedback welcome.
>
> On Wed, Aug 12, 2009 at 21:06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> > I'll try to come up with a patch for further discussion.
> > I think the grouping operator (...) will be handled directly by the
> parser
> > without surfacing to the closure and pipes interpreters, while the $(...)
> > for evaluation would be handled by those the way <...> currently works.
> >
> >
> > On Wed, Aug 12, 2009 at 15:37, Richard S. Hall <heavy@ungoverned.org
> >wrote:
> >
> >> On 8/12/09 4:00, Guillaume Nodet wrote:
> >>
> >>> So I'd rather have ( ... ) for pure grouping and $( ... ) for
> evaluating
> >>> as
> >>> we have in bash.
> >>>
> >>>
> >>>
> >>
> >> That seems reasonable to me.
> >>
> >> -> richard
> >>
> >>
> >>
> >
> >
> > --
> > 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
>
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
I've attached 2 patches to FELIX-1471 and FELIX-1325 to fix those issues.
Ftr, those are:
* use () for command grouping and $() for evaluation
* throw an exception when a command is not found, even if it has no
arguments
Feedback welcome.
On Wed, Aug 12, 2009 at 21:06, Guillaume Nodet <gn...@gmail.com> wrote:
> I'll try to come up with a patch for further discussion.
> I think the grouping operator (...) will be handled directly by the parser
> without surfacing to the closure and pipes interpreters, while the $(...)
> for evaluation would be handled by those the way <...> currently works.
>
>
> On Wed, Aug 12, 2009 at 15:37, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> On 8/12/09 4:00, Guillaume Nodet wrote:
>>
>>> So I'd rather have ( ... ) for pure grouping and $( ... ) for evaluating
>>> as
>>> we have in bash.
>>>
>>>
>>>
>>
>> That seems reasonable to me.
>>
>> -> richard
>>
>>
>>
>
>
> --
> 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
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
I'll try to come up with a patch for further discussion.
I think the grouping operator (...) will be handled directly by the parser
without surfacing to the closure and pipes interpreters, while the $(...)
for evaluation would be handled by those the way <...> currently works.
On Wed, Aug 12, 2009 at 15:37, Richard S. Hall <he...@ungoverned.org> wrote:
> On 8/12/09 4:00, Guillaume Nodet wrote:
>
>> So I'd rather have ( ... ) for pure grouping and $( ... ) for evaluating
>> as
>> we have in bash.
>>
>>
>>
>
> That seems reasonable to me.
>
> -> richard
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Gogo
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/12/09 4:00, Guillaume Nodet wrote:
> So I'd rather have ( ... ) for pure grouping and $( ... ) for evaluating as
> we have in bash.
>
>
That seems reasonable to me.
-> richard
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
2009/8/12 Guillaume Nodet <gn...@gmail.com>
> The problem is how to make the distinction between grouping and evaluation.
>
> In unix, we have the following:
> > echo echo a
> a
> > (echo echo a)
> echo a
> > ( (echo echo a) )
> echo a
> > $(echo echo a)
> a
> > $( $(echo echo a) )
> -bash: a: command not found
> > $( (echo echo a) )
> a
> > ( $(echo echo a) )
> a
>
> So we have a clear difference between () and $(), where () is only for
> grouping and has no effect on the evaluation, while $() will evaluate the
> content.
This is not quite true.
Unix always expects the word following '(' to be a command that it executes,
so () is NOT only for grouping, as its contents is executed as a command
pipeline.
$() first executes the contents just like (), and then it captures the
standard output and returns it as a string.
Note: in Unix, '(' can only appear where a command can appear, so the
following causes a syntax error:
$ echo hello (date)
-bash: syntax error near unexpected token `('
Gogo should allow () anywhere in a command line, and it should be replaced
by the value of the executed pipeline. This is possible in Gogo, because
commands can operate directly on Objects, not just strings like bash.
If we do use use $() in Gogo, then it should capture the output of the
command and replace it with a string.
However, this is less important, as most commands can deal with the object
directly. Those that can't can use 'tac'.
>
>
> The grouping operator is imho needed to be able to order pipes and columns:
> (echo a ; echo b) | tac
> echo a ; (echo b | tac)
I agree that we need the ability to control ordering.
However, this example works fine with the existing <> execution quotes:
karaf@root> <echo a; echo b> | tac
ab
karaf@root> echo a; <echo b | tac>
a
b
Now if I remove the ; so the result of the execution becomes an argument of
the first echo,
the result we get is intuitive:
karaf@root> echo a <echo b | tac>
ab
I have also compiled karaf using the FELIX-1471 patch:
The commands in the example also work as expected:
karaf@root> (echo a; echo b) | tac
ab
karaf@root> echo a; (echo b | tac)
a
b
but now when I remove the ; I get a non-intuitive result:
karaf@root> echo a (echo b | tac)
a(echo b | tac)
i.e. the () only cause execution at the beginning of a command.
so I'm now forced to use $() which seems unnecessary:
karaf@root> echo a $(echo b | tac)
ab
Ideally we would use the Unix default ordering, so that
echo a; echo b | tac
is treated as:
echo a; (echo b | tac)
Derek
>
>
> I think it might be confusing to conflate the two operators. We could use
> (( ... )) as an operator for evaluation though
>
> echo echo a => "echo a"
> (echo echo a) => "echo a"
> ((echo echo a)) => "a"
> (((echo echo a))) => "a"
> ((((echo echo a)))) => command not found
> (echo (echo echo a)) => "echo a"
> (echo ((echo echo a))) => "a"
> ((echo (echo echo a))) => "a"
> ((echo ((echo echo a)))) => command not found
>
> If we want () to be evaluating the content, we can't use it for grouping
> without evaluating ...
> In addition this syntax looks quite ugly ...
>
> So I'd rather have ( ... ) for pure grouping and $( ... ) for evaluating as
> we have in bash.
>
>
>
> On Tue, Aug 11, 2009 at 23:27, Derek Baum <de...@paremus.com> wrote:
>
> > 2009/8/11 Guillaume Nodet <gn...@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
>
>
> Did you mean "result: echo a" as the output ?
>
> >
> >
> > 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<ch...@gmail.com> wrote:
> > > > On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <de...@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 <pe...@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 <pe...@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
>
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
> > ((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
Did you mean "result: echo a" as the output ?
yes, that is the correct output for the example I gave.
I meant to give this example:
echo result: ((echo echo a)) => result: a
Derek
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
The problem is how to make the distinction between grouping and evaluation.
In unix, we have the following:
> echo echo a
a
> (echo echo a)
echo a
> ( (echo echo a) )
echo a
> $(echo echo a)
a
> $( $(echo echo a) )
-bash: a: command not found
> $( (echo echo a) )
a
> ( $(echo echo a) )
a
So we have a clear difference between () and $(), where () is only for
grouping and has no effect on the evaluation, while $() will evaluate the
content.
The grouping operator is imho needed to be able to order pipes and columns:
(echo a ; echo b) | tac
echo a ; (echo b | tac)
I think it might be confusing to conflate the two operators. We could use
(( ... )) as an operator for evaluation though
echo echo a => "echo a"
(echo echo a) => "echo a"
((echo echo a)) => "a"
(((echo echo a))) => "a"
((((echo echo a)))) => command not found
(echo (echo echo a)) => "echo a"
(echo ((echo echo a))) => "a"
((echo (echo echo a))) => "a"
((echo ((echo echo a)))) => command not found
If we want () to be evaluating the content, we can't use it for grouping
without evaluating ...
In addition this syntax looks quite ugly ...
So I'd rather have ( ... ) for pure grouping and $( ... ) for evaluating as
we have in bash.
On Tue, Aug 11, 2009 at 23:27, Derek Baum <de...@paremus.com> wrote:
> 2009/8/11 Guillaume Nodet <gn...@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
Did you mean "result: echo a" as the output ?
>
>
> 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<ch...@gmail.com> wrote:
> > > On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <de...@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 <pe...@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 <pe...@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
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
2009/8/11 Guillaume Nodet <gn...@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<ch...@gmail.com> wrote:
> > On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <de...@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 <pe...@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 <pe...@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
>
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
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<ch...@gmail.com> wrote:
> On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <de...@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 <pe...@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 <pe...@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
Re: Gogo
Posted by Hiram Chirino <ch...@gmail.com>.
On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum <de...@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 <pe...@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 <pe...@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/
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
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
2009/7/17 Peter Kriens <pe...@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 <pe...@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
>>>
>>>
>>>
>
Re: Gogo
Posted by Peter Kriens <pe...@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 <pe...@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
>>
>>
Re: Gogo
Posted by Derek Baum <de...@paremus.com>.
2009/7/16 Peter Kriens <pe...@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
>
>
Re: Gogo
Posted by Guillaume Nodet <gn...@gmail.com>.
In the changes I've made, i have not changed the assignment meaning to
turn everything into strings. What i did is to change the evaluation
of variables. For example, when a variable is adjacent to a string, it
will be converted to a string and concatenated. So
${a}b
will turn the a variable into a string and append 'b' to it, whereas
it was previously resulting into two arguments $a and 'b'.
However, no conversion is done if there is no other character before
or after the variable.
I've also aligned quotes handling with unix where expressions between
single quotes are not evaluated.
I don't really think i've broken anything and the parsing of the first
argument is still different than following arguments, but if i did, we
need more test cases to make sure we agree on what the results should
be.
For command not founds, i think people *are* confused that no error is
thrown. I do think the shell should report an error if the command
can't be found as in any other decent shell.
On Thursday, July 16, 2009, Peter Kriens <pe...@aqute.biz> wrote:
> I've read the threads about Gogo and have some remarks. At first, it made sense to make gogo closer to Unix. Though I think that each aspect needs to be argued on its merits, the fact that you have to learn a bit is imho not a big deal. Such thinking stifles innovation. That said, I do agree there should not be gratuitous differences.
>
> One example where the unix angle does not work is assignment. The TSL tries to be a script language with a shell feel. The biggest distinction is that it uses objects instead of strings. I think the variable assignment therefore should not assume a string. That is:
>
> $ a = hello world
>
> Is NOT a = "hello world". And I do not think it should be. In a script language, treating the right side as a string is silly and would surprise all script programmers (to use a slightly overused argument :-).
>
> 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.
>
> About the removal of need for whitespace, I think this might be problematic. I wanted to allow the use of URLs and not require silly escaping. That is why the parsing rules for the first word are different than the remainder. Removing the need for whitespace between between arguments will mess this up I think.
>
> i = open http://www.aqute.biz/page$q2
>
> I have not looked in detail if the fix to remove whitespace between variables is killing this or not. If not then I am ok with it, otherwise I have a bit of a problem with it. We could add strings where variables are expanded.
>
> 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.
>
> 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.
>
> 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
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Gogo
Posted by Peter Kriens <pe...@aqute.biz>.
I've read the threads about Gogo and have some remarks. At first, it
made sense to make gogo closer to Unix. Though I think that each
aspect needs to be argued on its merits, the fact that you have to
learn a bit is imho not a big deal. Such thinking stifles innovation.
That said, I do agree there should not be gratuitous differences.
One example where the unix angle does not work is assignment. The TSL
tries to be a script language with a shell feel. The biggest
distinction is that it uses objects instead of strings. I think the
variable assignment therefore should not assume a string. That is:
$ a = hello world
Is NOT a = "hello world". And I do not think it should be. In a script
language, treating the right side as a string is silly and would
surprise all script programmers (to use a slightly overused
argument :-).
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.
About the removal of need for whitespace, I think this might be
problematic. I wanted to allow the use of URLs and not require silly
escaping. That is why the parsing rules for the first word are
different than the remainder. Removing the need for whitespace between
between arguments will mess this up I think.
i = open http://www.aqute.biz/page$q2
I have not looked in detail if the fix to remove whitespace between
variables is killing this or not. If not then I am ok with it,
otherwise I have a bit of a problem with it. We could add strings
where variables are expanded.
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.
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.
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
Re: Karaf - Gogo - Help !
Posted by Guillaume Nodet <gn...@gmail.com>.
Fwiw, I've fixed the parser last week to handle "${ab}c" correctly...
On Tuesday, July 14, 2009, Derek Baum <de...@paremus.com> wrote:
> yes,
>
> ${x} actually defines a closure {...} and then immediately expands it.
> Commands typed directly into the shell also result in a closure being
> created and executed, so it is difficult to distinguish between:
>
>> x
>
> where we'd like it to fail with 'unknown command'
>
> and
>
>> ${x}
>
> where we'd like it to behave like $x
>
> RFC132 is keen to minimise unnecessary typing and so variables can be
> expanded directly without enclosing in {}.
>
> However, as in Unix shells,you sometimes need to delimit variables from the
> following text,
> for example x = "${ab}c". This is still possible in Gogo, without using ${}
> - e.g. "$ab'c'", but it is not as intuitive as "${ab}c" which is commonly
> used elsewhere.
>
> Derek
>
>
> 2009/7/14 Guillaume Nodet <gn...@gmail.com>
>
>> I think this is a feature, but I agree with you and I'd like to
>> consider it a bug too. However I think that's also why ${x}
>> evaluation works...
>>
>> On Monday, July 13, 2009, Hiram Chirino <ch...@gmail.com> wrote:
>> > I don't think the help command is supported yet..
>> >
>> > But on related note... to the gogo developers: I would have expected a
>> > command not found error when you type in a command that's not found.
>> This
>> > seems to work fine if you pass an argument to a command. It this a
>> > 'feature' or a bug?
>> >
>> > Regards,
>> > Hiram
>> >
>> >
>> > On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard <cmoulliard@gmail.com
>> >wrote:
>> >
>> >> Hi,
>> >>
>> >> I have done a build of Apache Felix Karaf this morning in order to test
>> it
>> >> but unfortunately Gogo does not seem to like Windows :
>> >>
>> >> Here is a snapshot of command used :
>> >>
>> >> karaf@root> karaf@root> help
>> >> help
>> >> karaf@root> karaf@root> ?
>> >> ?
>> >> karaf@root> karaf@root> help
>> >> help
>> >> karaf@root> karaf@root>
>> >>
>> >> We can't have access to help !
>> >> Where can I found the list of commands that we can use with Gogo
>> (compare
>> >> to
>> >> gshell) ?
>> >>
>> >> Regards,
>> >>
>> >> Charles Moulliard
>> >> Senior Enterprise Architect
>> >> Apache Camel Committer
>> >>
>> >> *****************************
>> >> blog : http://cmoulliard.blogspot.com
>> >>
>> >
>> >
>> >
>> > --
>> > 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
Re: Karaf - Gogo - Help !
Posted by Derek Baum <de...@paremus.com>.
yes,
${x} actually defines a closure {...} and then immediately expands it.
Commands typed directly into the shell also result in a closure being
created and executed, so it is difficult to distinguish between:
> x
where we'd like it to fail with 'unknown command'
and
> ${x}
where we'd like it to behave like $x
RFC132 is keen to minimise unnecessary typing and so variables can be
expanded directly without enclosing in {}.
However, as in Unix shells,you sometimes need to delimit variables from the
following text,
for example x = "${ab}c". This is still possible in Gogo, without using ${}
- e.g. "$ab'c'", but it is not as intuitive as "${ab}c" which is commonly
used elsewhere.
Derek
2009/7/14 Guillaume Nodet <gn...@gmail.com>
> I think this is a feature, but I agree with you and I'd like to
> consider it a bug too. However I think that's also why ${x}
> evaluation works...
>
> On Monday, July 13, 2009, Hiram Chirino <ch...@gmail.com> wrote:
> > I don't think the help command is supported yet..
> >
> > But on related note... to the gogo developers: I would have expected a
> > command not found error when you type in a command that's not found.
> This
> > seems to work fine if you pass an argument to a command. It this a
> > 'feature' or a bug?
> >
> > Regards,
> > Hiram
> >
> >
> > On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard <cmoulliard@gmail.com
> >wrote:
> >
> >> Hi,
> >>
> >> I have done a build of Apache Felix Karaf this morning in order to test
> it
> >> but unfortunately Gogo does not seem to like Windows :
> >>
> >> Here is a snapshot of command used :
> >>
> >> karaf@root> karaf@root> help
> >> help
> >> karaf@root> karaf@root> ?
> >> ?
> >> karaf@root> karaf@root> help
> >> help
> >> karaf@root> karaf@root>
> >>
> >> We can't have access to help !
> >> Where can I found the list of commands that we can use with Gogo
> (compare
> >> to
> >> gshell) ?
> >>
> >> Regards,
> >>
> >> Charles Moulliard
> >> Senior Enterprise Architect
> >> Apache Camel Committer
> >>
> >> *****************************
> >> blog : http://cmoulliard.blogspot.com
> >>
> >
> >
> >
> > --
> > 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
>
Re: Karaf - Gogo - Help !
Posted by Guillaume Nodet <gn...@gmail.com>.
I think this is a feature, but I agree with you and I'd like to
consider it a bug too. However I think that's also why ${x}
evaluation works...
On Monday, July 13, 2009, Hiram Chirino <ch...@gmail.com> wrote:
> I don't think the help command is supported yet..
>
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found. This
> seems to work fine if you pass an argument to a command. It this a
> 'feature' or a bug?
>
> Regards,
> Hiram
>
>
> On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard <cm...@gmail.com>wrote:
>
>> Hi,
>>
>> I have done a build of Apache Felix Karaf this morning in order to test it
>> but unfortunately Gogo does not seem to like Windows :
>>
>> Here is a snapshot of command used :
>>
>> karaf@root> karaf@root> help
>> help
>> karaf@root> karaf@root> ?
>> ?
>> karaf@root> karaf@root> help
>> help
>> karaf@root> karaf@root>
>>
>> We can't have access to help !
>> Where can I found the list of commands that we can use with Gogo (compare
>> to
>> gshell) ?
>>
>> Regards,
>>
>> Charles Moulliard
>> Senior Enterprise Architect
>> Apache Camel Committer
>>
>> *****************************
>> blog : http://cmoulliard.blogspot.com
>>
>
>
>
> --
> 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
Re: Karaf - Gogo - Help !
Posted by Hiram Chirino <ch...@gmail.com>.
I don't think the help command is supported yet..
But on related note... to the gogo developers: I would have expected a
command not found error when you type in a command that's not found. This
seems to work fine if you pass an argument to a command. It this a
'feature' or a bug?
Regards,
Hiram
On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard <cm...@gmail.com>wrote:
> Hi,
>
> I have done a build of Apache Felix Karaf this morning in order to test it
> but unfortunately Gogo does not seem to like Windows :
>
> Here is a snapshot of command used :
>
> karaf@root> karaf@root> help
> help
> karaf@root> karaf@root> ?
> ?
> karaf@root> karaf@root> help
> help
> karaf@root> karaf@root>
>
> We can't have access to help !
> Where can I found the list of commands that we can use with Gogo (compare
> to
> gshell) ?
>
> Regards,
>
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *****************************
> blog : http://cmoulliard.blogspot.com
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/