In all commands I've implemented, an error which is not handled by the command logic displays "usage" via ShellCommand.error().

I think this is the usual affair in unix world.

Fung thinks different, reassigning.

(1) Many UNIX commands do not print usage message when invalid arguments are passed to them. Attached screenshot (missing-operand.png) shows output from some very basic UNIX commands such as 'cp', 'mkdir', 'mv', 'rm', and 'rmdir' on a Linux machine when no arguments specified. They all generate a message similar to 'missing operand'.
(2) When I started working on Fluid Shell command implementation, when invalid arguments or required arguments are missing, I tried to be specific on the generated message to let user know what has been missing. See left hand side of the attached screenshot. Later on, I just followed the old UNIX way and display 'missing operand' or 'missing operands'.

I am not sure what is our preferred pattern, and reassign this issue to Niels for decision.

My two cents: I prefer generating a specific error message like many UNIX commands do so that user can know the problem right away.

I think we should be consistent.  We should provide the user useful information.  But we should spend too much effort at giving the user exactly the problem as it probably isn't necessary.  I think we should follow the format from Unix "grep" ...

Usage: COMMAND ....
Try '\help COMMAND' for more information.

unable to reproduce.

Change the default response to

Usage: COMMAND ....
Try '\help COMMAND' for more information.

implemented.

There are still commands that aren't conforming to the usage message format indicated by Andy.

e.g. : \list , \import , \export, \zip, \unzip, \gzip, \gunzip, \tar, \rename, \scp, \syncdir, \sendmail etc.

The following commands are implemented by me, all of them require one or more arguments to be presented on the command line:
   cp, describe, export, grep, gunzip, gzip, import, list, mkdir, mv,
   rename, rm, rmdir, scp, sendmail, syncdir, tail, tar, touch, unzip, zip
These commands now will call ShellCommand.error() if no arguments are specified.
ADS 11.0 branch, SVN r25576.

Fixed

Retested all the commands in ADStudio 12 Dev 34 for the message displayed when calling a command without parameters, and, except those commands that do not require a particular param in order to do a task (ie: alias, autocommit, cat, cd, clear, etc.), the following two commands do not respect the above agreed pattern (ie: Usage: COMMAND USAGE\n Try "\help COMMAND" for more information.):

$ ask
ask: VARIABLE_NAME: variable name must be specified<---It does not respect the above pattern
$ change
You must specify either a database or schema to change into<---It does not respect the above pattern

\ask and \change should confirm agreed pattern now. SVN r27335.

Please not that man page format is inconsistent at the moment, logged as issue #6963:
    https://www.aquaclusters.com/app/home/project/public/aquadatastudio/issue/6963
    Review fluid man page conventions

It seems that all the commands respect now the common error message pattern for executing a command without parameter.

I just reopened this issue because I thought about the different notation we use in this agreed pattern: shouldn't we eliminate the backslash prefixing help if there is no backslash prefixing COMMAND_USAGE?

$ COMMAND_NAME
Usage: COMMAND_USAGE<---No backslash in front of COMMAND_USAGE
Try "\help COMMAND_NAME" for more information.<---Then also eliminate the backslash prefixing help

Please note that the pattern for the COMMAND_USAGE part was logged as Issue ID 7082.

>> Try "\help COMMAND_NAME" for more information.<---Then also eliminate the backslash prefixing help

I am not sure about eliminating this.  You may need the backslash depending on what your Command Line Interpreter settings are on.  The message with the backslash is always correct.

>> I am not sure about eliminating this.  You may need the backslash depending on what your Command Line Interpreter settings are on.  The message with the backslash is always correct.

Yes, it all depends on the user's current command line settings. But this also means that calling help with a backslash prefix won't always work.

My idea was towards using a consistent format, the simplest solution being to eliminate the prefix, and in this case the end-user would have to add a specific prefix, if necessary, depending on his configuration.
Another solution would be to display the message dynamically based on his current CLI setup.

Reopening for consideration on last comment. If instead the currently displayed pattern with backslash (as in ADStudio 12 Alpha 35) is preferred, the issue can be closed.

>> But this also means that calling help with a backslash prefix won't always work.

I don't this is correct.  The reason we want to display "\help" is because that will always work.  The user can always use something else if they know how  ( eg : man command_name ).