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 (JIRA)" <ji...@apache.org> on 2009/07/13 18:57:15 UTC
[jira] Created: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
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.
>>
>>
>>
>
>
Re: [jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by Derek Baum <de...@paremus.com>.
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.
>
>
[jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Derek Baum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747159#action_12747159 ]
Derek Baum commented on FELIX-1325:
-----------------------------------
FELIX-1325-2.patch looks good - let's apply it and move on.
It's actually a superset of FELIX-1520.patch, and that's OK too.
> 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: Guillaume Nodet
> Priority: Minor
> Attachments: FELIX-1325-2.patch, FELIX-1325.patch, FELIX-1325.patch, FELIX-1325.patch
>
>
> 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.
[jira] Resolved: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet resolved FELIX-1325.
------------------------------------
Resolution: Fixed
Author: gnodet
Date: Tue Aug 25 06:34:31 2009
New Revision: 807497
URL: http://svn.apache.org/viewvc?rev=807497&view=rev
Log:
FELIX-1325: gogo doesn't report a command not found error unless an argument is supplied
Modified:
felix/trunk/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/shell/Closure.java
felix/trunk/gogo/runtime/src/test/java/org/apache/felix/gogo/runtime/shell/TestParser.java
> 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: Guillaume Nodet
> Priority: Minor
> Attachments: FELIX-1325-2.patch, FELIX-1325.patch, FELIX-1325.patch, FELIX-1325.patch
>
>
> 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.
[jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Derek Baum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742091#action_12742091 ]
Derek Baum commented on FELIX-1325:
-----------------------------------
Guillaume Nodet writes:
I think the following tests should be true:
assertEquals("echo b", c.execute("e = { $args } ; <e echo echo b | capture>"));
assertEquals("b", c.execute("e = { $args } ; <e echo <echo b> | capture>"));
assertEquals("b", c.execute("e = { $args } ; <<e echo echo b> | capture>"));
I think that most of the tests actually do one level too much evaluation.
The capture command is part of the test harness that returns System.in as a String, to make it easier to test results.
So why is the test: e.g.
assertEquals("echo b", c.execute("e = { $args } ; <e echo echo b | capture>"));
not written as:
assertEquals("echo b", c.execute("e = { $args } ; e echo echo b | capture"));
which remove the problematic final evaluation of the result, which may not be a command?
> 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
> Priority: Minor
> Attachments: FELIX-1325.patch, FELIX-1325.patch
>
>
> 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.
[jira] Assigned: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet reassigned FELIX-1325:
--------------------------------------
Assignee: Guillaume Nodet
> 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: Guillaume Nodet
> Priority: Minor
> Attachments: FELIX-1325.patch, FELIX-1325.patch, FELIX-1325.patch
>
>
> 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.
[jira] Updated: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Derek Baum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Derek Baum updated FELIX-1325:
------------------------------
Attachment: (was: FELIX-1325.patch)
> 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.
[jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Derek Baum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730498#action_12730498 ]
Derek Baum commented on FELIX-1325:
-----------------------------------
[reply to dev list added as issue comment]
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
> 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.
[jira] Assigned: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Derek Baum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Derek Baum reassigned FELIX-1325:
---------------------------------
Assignee: (was: Derek Baum)
Guillaume Nodet wrote:
> I think we should really keep the fact that ${c} is equivalent to $c
> I'll try to dig a bit and find a better way to report error not founds while still supporting ${c}.
I agree.
currently '${' is parsed as two tokens, so {} defines a closure and then the $ executes the closure.
The problem is that we need a 'command not found' error when executing a closure fails,
except when we are using ${x} just for variable expansion, as we didn't really want to define a closure anyway.
One way to achieve this would be to change the parser to recognise '${' as a single token,
and then use this for variable expansion. We could then also support default value substitution like bash e.g. ${myvar:-default value}.
> 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
> Priority: Minor
> Attachments: FELIX-1325.patch
>
>
> 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.
[jira] Updated: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet updated FELIX-1325:
-----------------------------------
Attachment: FELIX-1325.patch
Attach is an attempt to fix the issue.
There is one problem unfortunately which is related to command grouping.
I think the following tests should be true:
assertEquals("echo b", c.execute("e = { $args } ; <e echo echo b | capture>"));
assertEquals("b", c.execute("e = { $args } ; <e echo <echo b> | capture>"));
assertEquals("b", c.execute("e = { $args } ; <<e echo echo b> | capture>"));
However, there is no distinction between command grouping and execution. This is related to the discussion we had about using $() and () instead of <> and I think this problem should go away if we switch.
> 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
> Priority: Minor
> Attachments: FELIX-1325.patch, FELIX-1325.patch
>
>
> 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:51 PM, Hiram Chirino (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730509#action_12730509 ]
>
> Hiram Chirino commented on FELIX-1325:
> --------------------------------------
>
> Awesome.. from you comments and the issues you've opened up against the RFC, it seems we are in agreement that the osgi shell should be familiar to unix shell dudes.
> How often do they review the RFC feedback and accept/reject proposals?
>
It doesn't really operate smoothly like this, unfortunately. Right now,
the finalization of the R4.2 specs are consuming most of the cycles of
OSGi Alliance members and I don't think the shell is necessarily
targeted for this release. So, we might not hear too much right now, but
I will try to bug people.
-> richard
>
>> 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.
>>
>
>
[jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730509#action_12730509 ]
Hiram Chirino commented on FELIX-1325:
--------------------------------------
Awesome.. from you comments and the issues you've opened up against the RFC, it seems we are in agreement that the osgi shell should be familiar to unix shell dudes.
How often do they review the RFC feedback and accept/reject proposals?
> 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.
[jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737053#action_12737053 ]
Guillaume Nodet commented on FELIX-1325:
----------------------------------------
I think we should really keep the fact that ${c} is equivalent to $c
I'll try to dig a bit and find a better way to report error not founds while still supporting ${c}.
> 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
> Attachments: FELIX-1325.patch
>
>
> 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.
[jira] Closed: (FELIX-1325) gogo doesn't report a command not found
error unless an argument is supplied
Posted by "Derek Baum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Derek Baum closed FELIX-1325.
-----------------------------
> 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: Guillaume Nodet
> Priority: Minor
> Fix For: gogo-0.2.0
>
> Attachments: FELIX-1325-2.patch, FELIX-1325.patch, FELIX-1325.patch, FELIX-1325.patch
>
>
> 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.
[jira] Updated: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet updated FELIX-1325:
-----------------------------------
Attachment: FELIX-1325-2.patch
Patch to apply after FELIX-1520
> 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: Guillaume Nodet
> Priority: Minor
> Attachments: FELIX-1325-2.patch, FELIX-1325.patch, FELIX-1325.patch, FELIX-1325.patch
>
>
> 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.
[jira] Updated: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet updated FELIX-1325:
-----------------------------------
Attachment: FELIX-1325.patch
A simpler patch to apply after FELIX-1471 which fixes this issue
> 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
> Priority: Minor
> Attachments: FELIX-1325.patch, FELIX-1325.patch, FELIX-1325.patch
>
>
> 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.
[jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Derek Baum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730398#action_12730398 ]
Derek Baum commented on FELIX-1325:
-----------------------------------
Here's the patch to resolve as described:
svn diff src/main/java/org/apache/felix/gogo/runtime/shell/Closure.java
Index: src/main/java/org/apache/felix/gogo/runtime/shell/Closure.java
===================================================================
--- src/main/java/org/apache/felix/gogo/runtime/shell/Closure.java (revision 793625)
+++ src/main/java/org/apache/felix/gogo/runtime/shell/Closure.java (working copy)
@@ -166,6 +166,10 @@
{
return session.variables.remove(scmd);
}
+ else if (values.size() == 2)
+ {
+ return assignment(scmd, values.get(1));
+ }
else
{
Object value = execute(values.get(1), values.subList(2, values.size()));
> 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/14/09 11:48 AM, Hiram Chirino wrote:
> I guess I'm biased :)
>
> But really.. I don't care which shell variant TSL tries to emulate (Maybe
> the windows cmd.exe shell??).. I just hope it tries to emulate an existing
> one.
> Folks tend love it when you get incremental innovation. If you look at it,
> the basics of all the popular shells are pretty much consistent across all
> shell environments. I'm hoping the basics of TSL also follow suite.
>
I'd prefer something similar to a UNIX shell too, but in the end I can
live with changes if there are good reasons. I am hoping I can get Peter
Kriens to join this discussion, since he might have some rationale.
-> richard
>
> On Tue, Jul 14, 2009 at 11:36 AM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> On 7/14/09 10:58 AM, Hiram Chirino (JIRA) wrote:
>>
>>
>>> [
>>> https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730895#action_12730895]
>>>
>>> Hiram Chirino commented on FELIX-1325:
>>> --------------------------------------
>>>
>>> I agree those test cases are kinda invalid. The saddest bit there from a
>>> "don't surprise a unix shell guy" perspective is that ${c} is not the same
>>> as $c. Very sad.
>>>
>>>
>>>
>> I don't know if this is very sad or not. The goal isn't to re-create a UNIX
>> shell, sometimes you have to break with the past to do something new.
>> However, I agree it is better to avoid changing unnecessarily if you can.
>> But I wouldn't want to put undue pressure on the project to try to be like a
>> UNIX shell when it doesn't fit.
>>
>> And believe it or not, not everyone is intimately familiar with UNIX
>> shells. :-)
>>
>> -> richard
>>
>>
>>
>>>> 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
>>>> Attachments: FELIX-1325.patch
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>
>>>
>
>
>
Re: [jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by Hiram Chirino <ch...@gmail.com>.
I guess I'm biased :)
But really.. I don't care which shell variant TSL tries to emulate (Maybe
the windows cmd.exe shell??).. I just hope it tries to emulate an existing
one.
Folks tend love it when you get incremental innovation. If you look at it,
the basics of all the popular shells are pretty much consistent across all
shell environments. I'm hoping the basics of TSL also follow suite.
On Tue, Jul 14, 2009 at 11:36 AM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 7/14/09 10:58 AM, Hiram Chirino (JIRA) wrote:
>
>> [
>> https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730895#action_12730895]
>>
>> Hiram Chirino commented on FELIX-1325:
>> --------------------------------------
>>
>> I agree those test cases are kinda invalid. The saddest bit there from a
>> "don't surprise a unix shell guy" perspective is that ${c} is not the same
>> as $c. Very sad.
>>
>>
>
> I don't know if this is very sad or not. The goal isn't to re-create a UNIX
> shell, sometimes you have to break with the past to do something new.
> However, I agree it is better to avoid changing unnecessarily if you can.
> But I wouldn't want to put undue pressure on the project to try to be like a
> UNIX shell when it doesn't fit.
>
> And believe it or not, not everyone is intimately familiar with UNIX
> shells. :-)
>
> -> richard
>
>
>>
>>> 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
>>> Attachments: FELIX-1325.patch
>>>
>>>
>>> 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.
>>>
>>>
>>
>>
>>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
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/14/09 10:58 AM, Hiram Chirino (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730895#action_12730895 ]
>
> Hiram Chirino commented on FELIX-1325:
> --------------------------------------
>
> I agree those test cases are kinda invalid. The saddest bit there from a "don't surprise a unix shell guy" perspective is that ${c} is not the same as $c. Very sad.
>
I don't know if this is very sad or not. The goal isn't to re-create a
UNIX shell, sometimes you have to break with the past to do something
new. However, I agree it is better to avoid changing unnecessarily if
you can. But I wouldn't want to put undue pressure on the project to try
to be like a UNIX shell when it doesn't fit.
And believe it or not, not everyone is intimately familiar with UNIX
shells. :-)
-> richard
>
>> 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
>> Attachments: FELIX-1325.patch
>>
>>
>> 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.
>>
>
>
[jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730895#action_12730895 ]
Hiram Chirino commented on FELIX-1325:
--------------------------------------
I agree those test cases are kinda invalid. The saddest bit there from a "don't surprise a unix shell guy" perspective is that ${c} is not the same as $c. Very sad.
> 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
> Attachments: FELIX-1325.patch
>
>
> 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.
[jira] Updated: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Derek Baum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Derek Baum updated FELIX-1325:
------------------------------
Attachment: FELIX-1325.patch
replace previous attachment that inadvertently included a change not associated with this issue.
> 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
> Attachments: FELIX-1325.patch
>
>
> 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.
[jira] Commented: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "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.
[jira] Updated: (FELIX-1325) gogo doesn't report a command not
found error unless an argument is supplied
Posted by "Derek Baum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Derek Baum updated FELIX-1325:
------------------------------
Attachment: FELIX-1325.patch
I attach the full patch including update to tests for this change.
I will not commit it for a few days to allow time for comments from the dev list.
Many of the tests made extreme use of command evaluation defaulting to the value if not found.
For example:
assertEquals("a b", c.execute("echo ${c} b | capture"));
here the ${c} forces c to be evaluated as a command, which now fails with command not found
assertEquals("3", c.execute("[a=2 <b>=<3>] get b").toString());
here the <b> and <3> would now fail as b and 3 are not defined as commands
assertEquals("a", c.execute("e = { echo $0 } ; <e a b | capture>"));
here e a b produces a, but the <> cause a to be evaluated again, which fails as it is not defined as a command.
> 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
> Attachments: FELIX-1325.patch
>
>
> 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.