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<chir...@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/
