myapp /?
myapp -help
myapp -ver
etc....
myapp /?
myapp -help
myapp -ver
etc....
A short and long version of command line arguments. Check if there is a getopt
library port for the programming language that you use. It will help you in parsing command line arguments.
--config-file=FILE | -C FILE
--help | -h
--usage | -u
--version | -v
Include other relevant options for your application.
I'd suggest to have option for help, version, output verbosity settings. The other switches are depending on your application.
It depends on the platform.
On Windows, /? or /h or /help are common.
On Unix, a command should have a man page.
On Unix variants in which Gnu conventions are followed (e.g. Linux), it should respond to --help and --version. Even better, it can integrate with bash autocompletion.
Apart from that, look at other programs' in the same area as yours and use the same options where it makes sense. E.g.:
If your program accepts file names as arguments then common convention is for a single hyphen to mean 'read from stdin' and a double hyphen to mean 'treat the next argument as a file even if it begins with a hyphen'.
GNU Coding Standards mandate --version
and --help
and I've come to expect any CLI program to support these. Other than that, it really depends on what the program is, but here are some other suggestions: -q
or --quiet
for less output, -v
or --verbose
for more output, -d
or --debug
for debugging output.
-h is a must on *nix. I'd say the same for /? on Windows, but programs available for both platforms usually go for the *nix style. It's probably because of getopt and friends.
Some essentials:
-h, --help
-v, --version
-u, --usage
If the application modifies any files at all:
--dry-run Do not modify any files (but work as if you did)
If the application uses config files, options to use a specified config file or directory.
Some main operational switches to run non-interactively and do the job:
mysql --execute="SELECT * FROM ..."
cmd.exe /C "dir"
Eric S. Raymond gives a great overview of most common UNIX command line options in his great book The Art of Unix Programming. It mostly talks about single-letter options, but a great resource on that matter nevertheless.
I agree to all of the arguments mentioned above but would like to point out another thing: You might want your application to accept long, short and BSD style for all arguments. Of course BSD style could be ommited if you feel that none of your users will be comfortable using it. The long style helps to add sense to the arguments and makes them easier to remember when getting started with the application.