Improve shell behaviour for commands invoked with invalid arguments

I wasn't going to comment on this for now, but an email has prompted to do so.

Firstly, I think that the current JNode shell/syntax infrastructure is already a lot better than UNIX / Linux shells in terms of usability for new users:

• The syntax information produced by "help" is guaranteed to be complete and accurate.
• The syntax mechanism ensures that argument handling is predictable and a lot more consistent.
• Argument completion really helps when you are not familiar with (or have forgotten) a command's syntax.

Second, current thinking is that command-line stuff is really only for "power users". I wish this wasn't the case, but sadly most computer users will run a mile if you don't give them dumbed down point and click interfaces. What this means that we can probably rely on JNode shell users being willing to run "help" and read online command documentation. (Call me old fashioned ... but this approach was just fine for me when I learned to use UNIX.)

Now to some specifics:

• The idea of making an "educated guess" is a bit naive. Like any generic parser, the JNode command argument parser is dumb; it is blindly following a syntax, with no knowledge of what it actually means. By contrast, the parser in a typical compiler has some hard-wired "knowledge" of the meaning of what it is parsing and can (on a good day) produce pretty accurate error messages.
• In theory it would be possible to work out a "closest match" based on some heuristics; e.g. based on the number of symbols consumed. But that is really just a heuristic ... and the closest match may bear no relation to what the user is actually trying to do. Besides, getting a typical parser to report where it is in a grammar in a way that is user comprehensible is actually rather hard. In our case, we'd have to deal with the Syntax / MuSyntax layering in order to get get a meaningful description.
• Finally even the idea of reporting the usage when no arguments are given is problematic. Do we really want to encourage people to try entering alias names to see if they give a usage message? Consider "exit" for example ...

If I was going to do anything in this area, I'd try to do it by adding new methods to the "CommandCompleter" API which would bind to some currently un-bound control key. For example: CTRL-U might mean "display usage". But I wouldn't try the more complicated stuff. It would be very difficult and IMO the results would at best be mediocre.

As I suggested, if you think making a guess is too hard in the current command argument parsing system then printing out the usage info is still better than a generic and nothing-telling error message.

I disagree. You are presuming that the user wants to see a usage message every time he / she gets the command line syntax incorrect. I would find that kind of behavior annoying.

If I want to see usage information, I'm happy to type "help <command>" or "usage <command>", or "<command> ^U" or ...

But I really think that there are more important things to fix.

I have implemented a simple incremental help mechanism.

If you enter a partial command (with a complete alias / classname) followed by ESC or CTRL-?, the shell will now display the command's usage message(s). If the command line is a pipeline, the usage for the last command is shown. (This is implemented for the 'default' and 'redirecting' interpreters ... not the 'bjorne' interpreter yet)

I'm marking this issue fixed as I don't intend to implement any of the other ideas for the reasons previously stated.

Automatically closed -- issue fixed for two weeks with no activity.