You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Derek Baum <de...@paremus.com> on 2009/07/13 22:06:47 UTC
Re: [jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
I would also be happy with
> x = hello world
> x = "hello world"
being equivalent.
Gogo is based on RFC132, <
http://www.osgi.org/download/osgi-4.2-early-draft.pdf>
which defines the syntax of the TSL Language, so we need to be careful about
making apparently trivial changes that conflict with the RFC, as Gogo would
not then be compatible with other RFC132 implementations.
However, RFC132 is only a draft and I'm sure that constructive comments will
be welcomed.
I have already raised some at osgi.org: <
https://www.osgi.org/bugzilla/buglist.cgi?bug_status=__open__>
The use of backquotes for command execution was considered in the RFC, but
rejected because they can't easily be nested. However, bash and all modern
shells now support $(...) as an alternative to backquotes, and this
construct can be nested.
RFC132 already uses parenthesis () to create a literal LDAP expression. I'm
not sure that this is very useful, as a converter could be registered to
convert a string to an LDAP expression when required. This would then make
parenthesis available to be used as $(). I have mentioned this in
https://www.osgi.org/bugzilla/show_bug.cgi?id=50
Derek
2009/7/13 Hiram Chirino (JIRA) <ji...@apache.org>
>
> [
> https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730430#action_12730430]
>
> Hiram Chirino commented on FELIX-1325:
> --------------------------------------
>
> That raises more questions for me.
>
> For me the sane way for a shell to handle assignment statements would have
> been something like this.
>
> > x=Hello World
> > x="Hello World"
>
> Either of the above are equivalent. And no Hello is not executed as
> command. If you do want to evaluate a command, it would be something like:
>
> > x=<Hello World>
>
> I would have preferred, using `Hello World` over <Hello World>, but it
> seems you guys prefer the latter because it is easier to parse recursive
> constructs.
>
> Make sense?
>
>
>
> > gogo doesn't report a command not found error unless an argument is
> supplied
> >
> ----------------------------------------------------------------------------
> >
> > Key: FELIX-1325
> > URL: https://issues.apache.org/jira/browse/FELIX-1325
> > Project: Felix
> > Issue Type: Improvement
> > Components: Gogo
> > Reporter: Derek Baum
> > Assignee: Derek Baum
> > Priority: Minor
> >
> > 2009/7/13 Hiram Chirino <ch...@gmail.com> wrote:
> > 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?
> > This is a 'feature', in that an undefined command silently returns
> itself, rather than an error.
> > This is so that:
> > > x = hello
> > works; otherwise the assignment would fail, with a command not found
> error.
> > Note: that
> > > x = hello world
> > will actually evaluate the 'hello' command with 'world' as an argument.
> > > x = "hello world"
> > tries to evaulate the 'hello world' command, which probably doesn't
> exist, so it falls back to returning the value, rather than unknown command.
> > I think this can be simply resolved by avoiding re-evaluating an
> assignment with a single argument.
> > This will mean that
> > > x = hello
> > works as it does currently, but that
> > > hello
> > will fail with 'unknown command', rather than simply return itself.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Re: [jira] Commented: (FELIX-1325) gogo doesn't report a command
not found error unless an argument is supplied
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/13/09 4:06 PM, Derek Baum wrote:
> I would also be happy with
>
>
>> x = hello world
>> x = "hello world"
>>
>
> being equivalent.
>
> Gogo is based on RFC132,<
> http://www.osgi.org/download/osgi-4.2-early-draft.pdf>
> which defines the syntax of the TSL Language, so we need to be careful about
> making apparently trivial changes that conflict with the RFC, as Gogo would
> not then be compatible with other RFC132 implementations.
>
I think this is an important point to keep in mind. The point of Gogo is
to try to standardize on a shell for OSGi frameworks, so if you want to
run completely wild, you will likely need to create your own
shell...which is fine.
> However, RFC132 is only a draft and I'm sure that constructive comments will
> be welcomed.
> I have already raised some at osgi.org:<
> https://www.osgi.org/bugzilla/buglist.cgi?bug_status=__open__>
>
And this is another important point to keep in mind too. The whole point
of doing this in the open is to feed reasonable comments into the RFC
before it becomes a spec.
We have a balancing act to perform.
-> richard
> The use of backquotes for command execution was considered in the RFC, but
> rejected because they can't easily be nested. However, bash and all modern
> shells now support $(...) as an alternative to backquotes, and this
> construct can be nested.
>
> RFC132 already uses parenthesis () to create a literal LDAP expression. I'm
> not sure that this is very useful, as a converter could be registered to
> convert a string to an LDAP expression when required. This would then make
> parenthesis available to be used as $(). I have mentioned this in
> https://www.osgi.org/bugzilla/show_bug.cgi?id=50
>
>
> Derek
>
> 2009/7/13 Hiram Chirino (JIRA)<ji...@apache.org>
>
>
>> [
>> https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730430#action_12730430]
>>
>> Hiram Chirino commented on FELIX-1325:
>> --------------------------------------
>>
>> That raises more questions for me.
>>
>> For me the sane way for a shell to handle assignment statements would have
>> been something like this.
>>
>>
>>> x=Hello World
>>> x="Hello World"
>>>
>> Either of the above are equivalent. And no Hello is not executed as
>> command. If you do want to evaluate a command, it would be something like:
>>
>>
>>> x=<Hello World>
>>>
>> I would have preferred, using `Hello World` over<Hello World>, but it
>> seems you guys prefer the latter because it is easier to parse recursive
>> constructs.
>>
>> Make sense?
>>
>>
>>
>>
>>> gogo doesn't report a command not found error unless an argument is
>>>
>> supplied
>>
>> ----------------------------------------------------------------------------
>>
>>> Key: FELIX-1325
>>> URL: https://issues.apache.org/jira/browse/FELIX-1325
>>> Project: Felix
>>> Issue Type: Improvement
>>> Components: Gogo
>>> Reporter: Derek Baum
>>> Assignee: Derek Baum
>>> Priority: Minor
>>>
>>> 2009/7/13 Hiram Chirino<ch...@gmail.com> wrote:
>>> 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?
>>
>>> This is a 'feature', in that an undefined command silently returns
>>>
>> itself, rather than an error.
>>
>>> This is so that:
>>>
>>>> x = hello
>>>>
>>> works; otherwise the assignment would fail, with a command not found
>>>
>> error.
>>
>>> Note: that
>>>
>>>> x = hello world
>>>>
>>> will actually evaluate the 'hello' command with 'world' as an argument.
>>>
>>>> x = "hello world"
>>>>
>>> tries to evaulate the 'hello world' command, which probably doesn't
>>>
>> exist, so it falls back to returning the value, rather than unknown command.
>>
>>> I think this can be simply resolved by avoiding re-evaluating an
>>>
>> assignment with a single argument.
>>
>>> This will mean that
>>>
>>>> x = hello
>>>>
>>> works as it does currently, but that
>>>
>>>> hello
>>>>
>>> will fail with 'unknown command', rather than simply return itself.
>>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>
>
>