Human Interface Guidelines for Command Line Applications

Human Interface Guidelines for Command Line Applications. I've always wished that Command Line apps were a little more usable. I think that a few guidelines, if followed would make the command far more approachable and intuitive. The GNU habit of using single dashes for abbreviated arguments and double dashes for full text is handy, but can often be confusing when described in man, info and simple descriptions. I am sure that there is documentation on these design standards for GNU tools, but until I find it, I wanted to post these ideas, based on what I have found useful in the command line apps I have used. * All programs, when run with no arguments, should not execute but display a simple description and list of common commands.
Example:

$>foo Description:

foo is a sample application meant to serve as a example of proper command line behavior.

Examples:

To start foo: foo --start
To start foo with a file: foo --start filename.ext

* When running in a non-interactive manner, a command to stop the program should be displayed.
Example:

$>foo --start
To stop foo, press control+x at any time.

* If the program is passed an argument that it does not understand, it should produce a "friendly" error message and display the simple description.
Example 1:

$>foo --bar
foo does not understand your request to "bar"
Description:

foo is a sample application meant to serve as a example of proper command line behavior.

Examples:

To start foo: foo --start
To start foo with a file: foo --start filename.ext

Example 2:

$>foo bar
foo could not find a file named "bar"
Description:

foo is a sample application meant to serve as a example of proper command line behavior.

Examples:

To start foo: foo --start
To start foo with a file: foo --start filename.ext