What are good habits for designing command line arguments?

Question

While developing the application I started to wonder - How should I design command line arguments?

A lot of programs are using formula like this -argument value or /argument value. Solution which came to my mind was argument:value. I thought it is good because with no white spaces there is no way that values and arguments can be messed up. Also it is easy to split a string into two on the first from the left : character.

My questions are:

1. Is popular -argument value formula better than argument:value (more readable, easier to write, bugfree, easier to understand by expert developers)?
2. Are there some commonly known rules which I should follow while designing command line arguments (other than if it works it is OK)?

---

Asked for some more details I will provide it. However I think they should not affect the answers. The question is about a good habits in general. I think they are all the same for all kinds of applications.

We are working on an application which will be used in public places (touch totems, tables). Applications are written using Qt Quick 5 (C++, QML, JS). Devices will have Windows 8.1/10 installed. We will provide front-end interface to manage the devices. However some advanced administrators may want to configure the application on their own. It is not very important from the side of the business but as I agree with what Kilian Foth said I do not want my application to be a pain for a user. Not finding in the Internet what I want I asked here.

---

To more advanced Stack Exchange users: I wanted this question to be general. Maybe it qualifies to the community wiki (I do not know if existing question can be converted with answers). As I want this question to be operating system and programming language independent the answers appearing here can be a valuable lesson for other developers.

Answer 1

On POSIX systems (e.g. Linux, MacOSX), at least for programs possibly started in a shell terminal (e.g. most of them), I would recommend using the GNU coding conventions (which also lists common argument names) and look into the POSIX utilities guidelines, even for proprietary software:

• always handle --version and --help (even /bin/true accepts them!!). I curse the authors of software not understanding --help, I hate them (because prog --help is the first command I am trying on a new program)! Often --help can be abbreviated as -h

• Have the --help message list all the options (unless you have too many of them... in that case list the most common ones and explicitly refer to some man page or some URL) and default values of options, and perhaps important (and program-specific) environment variables. Show these option lists on option argument error.

• accept -a short argument (single letter) and have some equivalent --long-argument, so -a2 --long-argument=2, --long-argument 2; of course you could have (for rarely used options) some --only-long-argument name; for modal arguments without extra options -cf is generally handled as -c -f, etc. so your -argument:value proposal is weird, and I don't recommend doing that.

• use GLIBC getopt_long or better (e.g. argp_parse, in OCaml it's Arg module, ...)

• often use - for standard input or output (if you can't do that, handle /dev/stdin & /dev/stdout even on the few operating systems not having them)

• mimic the behavior of similar programs by reusing most of their options conventions; in particular -n for dry run (à la make), -h for help, -v for verbosity, etc...

• use -- as separator between options & file or other arguments

• if your program uses isatty to test than stdin is a terminal (and behave "interactively" in that case), provide an option to force non-interactive mode, likewise if your program has a GUI interface (and tests getenv("DISPLAY") on X11 desktop) but could also be used in batch or command line.

• Some programs (e.g. gcc) accept indirect argument lists, so @somefile.txt is meaning read program arguments from somefile.txt; this could be useful when your program might accept a very big lot of arguments (more than your kernel's ARG_MAX)

BTW, you might even add some auto-complete facilities for your program and usual shells (like bash or zsh)

Some old Unix commands (e.g. dd, or even sed) have weird command arguments for historical compatibility. I would recommend not following their bad habits (unless you are making some better variant of them).

If your software is a series of related command-line programs, take inspiration from git (which you surely use as a development tool), which accepts git help and git --help and have many gitsubcommand and gitsubcommand--help

In rare cases you might also use argv[0] (by using symlinks on your program), e.g. bash invoked as rbash has a different behavior (restricted shell). But I usually don't recommend doing that; it might make sense if your program could be used as a script interpreter using shebang i.e. #! on first line interpreted by execve(2). If you do such tricks, be sure to document them, including in --help messages.

Remember that on POSIX the shell is globbing arguments (before running your program!), so avoid requiring characters (like * or $ or ~) in options which would need to be shell-escaped.

In some cases, you could embed an interpreter like GNU guile or Lua in your software (avoid inventing your own Turing-complete scripting language if you are not expert in programming languages). This has deep consequences on the design of your software (so should be thought of early!). You should then easily be able to pass some script or some expression to that interpreter. If you take that interesting approach, design your software and its interpreted primitives with care; you could have some weird user coding big scripts for your thing.

In other cases, you might want to let your advanced users load their plugin into your software (using dynamic loading techniques à la dlopen & dlsym). Again, this is a very important design decision (so define and document the plugin interface with care), and you'll need to define a convention to pass program options to these plugins.

If your software is a complex thing, make it accept some configuration files (in addition or replacement of program arguments) and probably have some way to test (or just parse) these configuration files without running all the code. For example, a mail transfer agent (like Exim or Postfix) is quite complex, and it is useful to be able to "half-dry" run it (e.g. observing how it is handling some given email address without actually sending an email).

---

^{Notice that the /option is a Windows or VMS thing. It would be insane on POSIX systems (because the file hierarchy uses / as a directory seperator, and because the shell does the globbing). All my answer is mostly for Linux (and POSIX).}

---

P.S. If possible, make your program a free software, you would get improvements from some users & developers (and adding a new program option is often one of the easiest things to add to an existing free software). Also, your question depends a lot on the intended audience: a game for teenagers or a browser for grandma probably does not need the same kind and amount of options than a compiler, or a network inspector for datacenter sysadmins, or a CAD software for microprocessor architects or for bridge designers. An engineer familiar with programming & scripting probably likes much more having lots of tunable options than your grandma, and probably might want to be able to run your application without X11 (perhaps in a crontab job).

Answer 2

The fact that a data format convention is popular is its advantage.

You can easily see that using = or : or even ' ' as a separator are trivial differences that could be converted into each other by computer with little effort. What would be a big effort is for a human to remember "Now see, did this infrequently-used program delimit things with : or with = ? Hmmm..."

In other words, for the love of god, don't deviate from extremely entrenched conventions without a compelling reason. People will remember your program as "the one with the weird and annoying cmdline syntax" instead of "the one that saved my college essay".

Answer 3

In layman's terms

When in Rome, do as the Romans do.

• If your CLI app is intended for Linux/Unix use the -p value or --parameter value convention. Linux has tools for parsing such parameters and flags in an easy way.

I usually do something like this:

while [[ $# > 0 ]]
do
key="$1"
case $key in
    --dummy)
    #this is a flag do something here
    ;;
    --audit_sessiones)
    #this is a flag do something here
    ;;
    --destination_path)
    # this is a key-value parameter
    # the value is always in $2 , 
    # you must shift to skip over for the next iteration
    path=$2
    shift
    ;;
    *)
    # unknown option
    ;;
esac
shift
done

• If your CLI app is intended for Windows, then use /flag and /flag:value conventions.

• Some apps like Oracle use neither though. Oracle utilities use PARAMETER=VALUE.

• One thing I like to do is, besides accepting parameters in the command line, providing the option of using a parfile, which is a key-value pair file to avoid lengthy parameter chains. For that you should provide an additional --parfile mifile.par parameter. Obviously if --parfile is used, all other parameters are discarded in favor of what's inside the parfile.

• An additional suggestion is allowing the use of some custom environment variables, for example, setting environment variable MYAPP_WRKSPACE=/tmp would make it unnecessary to always set --wrkspace /tmp.

• In Linux don't forget to add parameter auto-completion, meaning users can type half a switch, hit TAB and then shell would complete it for them.

Answer 4

One thing that didn't come up yet:

Try to design your software from the command line arguments upwards. Meaning:

Before designing the functionality, design the user interface.

This will allow you to drill down on edge cases and common cases early on. Of course you'll still abstract the outside and the inside, but it's going to give much better result than just writing all the code and then slamming a CLI to it.

Furthermore, check out docopt (http://docopt.org/).

docopt is a great help with that in many languages, especially for python where you have severely limited, user-adverse argument parsers like argparse still being considered as "OK". Instead of having parsers and subparsers and conditional dicts, you just define the syntax help (according to the matching POSIX standard) and it does the rest.

Answer 5

Some valuable comments provided already (@Florian, Basile), but let me add ... OP says,

We will provide front-end interface to manage the devices. However some advanced administrators may want to configure the application on their own

But also remarks:

I did not want this question to be platform or language specific

You must consider your target audience - advanced administrators. What platform do they normally work on - Win/ Unix/ Mac? And what platform does you app run on? Follow whatever CLI conventions have already been established for that platform. Do your "advanced" admins want/ need a GUI based tool?

You want the interface to be consistent internally and with other admin tools. I don't want to stop and think is it cmd -p <arg> or cmd -p:<arg> or cmd /p <arg>. Do I need quotes 'cos there's a space? Can I cmd -p <val1> <val2> or cmd -p <val1> -p <val2> for multiple targets? Are they order specific? Overloadable? Does cmd -p2 <arg> -p1 <arg> work too? Does ls -l -r -t dir1 dir2 == ls -trl dir1 dir2 ?

For my Unix admin tools, I have always kept the guidance provided by Heiner's Shelldorado in mind along with the other references mentioned.

As important as designing the CLI is to make sure your application is designed to work with command line arguments the same as from the GUI - ie: no business logic in the GUI or use the common command called from both GUI and CLI.

Most UNIX based administrative tools are actually designed first as command lines tools and the provided GUI simply facilitates "populating" the options for the command line. That approach allows for automation, use of response files, etc. and hands-off management (less work for me!)

As classic toolset used w/this approach is Tcl/Tk. Not suggesting you switch tools; just consider design approach from writing a GUI-based administrative app to the app as a command line tool first; then layer the GUI on top for convenience. At some point you'll likely discover the GUI is a pain (and error prone) if you have to do multiple configs and re-entering generally the same options over and over and you'll look for an automated approach.

Remember your admin likely has to type in the correct values in the correct boxes anyway, so how much effort are you relieving anyway w/GUI ?