felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [jira] Commented: (FELIX-1325) gogo doesn't report a command not found error unless an argument is supplied
Date Tue, 14 Jul 2009 15:36:18 GMT
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<chirino@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.

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