I need to rollout an application in appliance form factor and have been asked to design a CLI as exposing BASH is problematic from a simplicity/usability perspective. I would like to understand the best practices for CLI development around:
The Unix way of thinking should always apply to CLI program development.
Standalone and Filter
Work out if you want your CLI app to be an interface or a filter. Filters are handy and follow the Unix philosophy. As an example, if your CLI app is an administration app, include options for outputting status or current configuration as XML or another format. This way your application can be a filter and transformer of information as well as an interactive application.
Librification
I often find it helps to write the core functionality as a library, and write the executable as frontend. This makes it simpler to write a GUI in the future or bind the library to your dynamic language of choice.
Security
As well as good programming practice in the program, the OS environment offers alot of security, so take advantage of all POSIX has to offer. Filesystem permissions, in-code user checking and safeguards. If you only want your program accessible over SSH, then create a special user for this and only give that user permissions. If your app is interactive then set it as the user's shell on login.
Wizards
Are not really seen too much in CLI-land. You typically want your CLI app to mimic a fat-function. Atomic operations on CLI arguments that provide a return code. If you want a library, create a wrapper for the executable that extends it. The executable should be a CLI-accessible library in effect.
Arguments and convention
Making your arguments conventional is important. Look at conventions in your current environment... does
-v
Conventionally mean verbose output or print version information? Look at the GNU standards on long and short arguments such as:
-v or --version
And use an argument processing library such as getopt.
What I do
I always treat a CLI executable as a library bound to the shell acting as a filter so that I can pipe and redirect output to files and other utilities.
Recommended Reading
Linux Application Development - Johnson, Troan
Hope this helps and Good Luck
As you design the interface, it might be helpful to construct a keystroke-level model. For example, take the command mkdir foo
If one were to invoke this command, one would have to:
Those are helpful things to keep in mind - as Aiden said, you want to make it easy to recall options, by using standards (like "-v" for "version")
With a keystroke-model, you can map out how much time it might take a user to invoke the command. You can look at the model and see if there are points of redundancy you could possibly eliminate - eg, see if "mental preparation" could be replaced by some smarter behavior from your program.
Wikipedia has a decent article about these kinds of models (though I learned about them from Steven Heim's book.)
That doesn't exactly answer the points in your OP, but this might be a helpful way to evaluate the CLI you create. Best of luck!
cpan - easily interact with CPAN from the command line
This script launches the CPANPLUS utility to perform various operations from the command line, or if it's invoked without arguments, an interactive shell is executed by default.
The DBI::Shell module (and dbish command, if installed) provide a simple but effective command line interface for the Perl DBI module.
ldapsh is an interactive LDAP shell, written entirely in perl and using Net::LDAP. It's extensible in that it is relatively easy to add new commands to it. It is largely modeled after the Unix shell.
JSON::Shell - an interactive shell for performing JSON and JSON-RPC requests
This module is an interactive client to a JSON-RPC service.
psftp is an interactive SFTP client written in Perl, using the Net::SFTP::Foreign::Compat libraries. It is very similar in functionality to the sftp program that is part of both OpenSSH and ssh2.