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.

  • 17
    Look to popular command line tools. For example, the single hyphen is often used to allow combining options. e.g. you might write ls -ltr to combine the options -l, -t and -r. GNU style programs also typically allow word-based options with a double hyphen like --reverse instead of -r. There are other popular conventions like -h to show help, -- to signal the end of options, specifying - as a filename to allow reading from stdin, etc.
    – Brandin
    Commented Jan 15, 2016 at 9:48
  • 78
    Neither -argument value not -argument:value are common. Common are -a value, -avalue, and --argument=value. Commented Jan 15, 2016 at 10:16
  • 42
    Use a popular command line parsing library (usually called something like getopt(s)) where you can. Commented Jan 15, 2016 at 10:17
  • 5
    @k3b We are working with Qt. As kevin cline said in his comment we can use already available library. I suppose it is multi-platform and well-thought. QCommandLineParser Commented Jan 15, 2016 at 11:26
  • 14
    The problem with your final blurb is that argument parsing is not a platform-independent issue.
    – pydsigner
    Commented Jan 15, 2016 at 14:57

5 Answers 5


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).

  • 19
    Agreed, but git is a better example. I won't recommend even looking into cvs in 2016. Commented Jan 15, 2016 at 10:01
  • 8
    + in case of invalid option just show help. It's SOOOO annoying to get a useless error message for example for dd -h.
    – domen
    Commented Jan 15, 2016 at 11:42
  • 8
    GNU programs support --help as a rule but often don't recognize -h which is annoying. I usually type -h when I forget an option to a program, it is annoying to have to retype the command with the longer option --help. After all, I typed -h because I forgot something. Why should the user be expected to remember which progams require '--help' and which programs require '-h' to show the help screen? Just include an option for both -h and --help.
    – Brandin
    Commented Jan 15, 2016 at 12:42
  • 33
    The first part of this answer is good but somewhere along you are kind of go off on tangents. For example, configuration files, plugins and dlopen, choices of software licenses and Web browsers aren't really related to the conventions of a command line interface anymore.
    – Brandin
    Commented Jan 15, 2016 at 13:58
  • 6
    And please. If you do format your output for screen, add an output format override. Nothing annoys me more than commands that truncate or wrap lines when I am trying to use them in a script.
    – Sobrique
    Commented Jan 17, 2016 at 12:52

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".

  • 19
    for almost all languages there are library functions to handle command line arguments. Use one of them. Commented Jan 15, 2016 at 8:43
  • 9
    Good advice, but what are those conventions? -1
    – RubberDuck
    Commented Jan 15, 2016 at 10:20
  • 14
    There is an interesting example of a commonly used UNIX tool which violates this convention intentionally: dd uses a key=value syntax. The reason for this design decision is that this tool (nickname: data destroyer) can cause a lot of damage when used incorrectly. By forcing the user to abandon their usual habit they force the user to think more closely about what they are doing.
    – Philipp
    Commented Jan 15, 2016 at 11:32
  • 18
    Are you sure that is the reason for dd? I believe that it simply was coded at a time (1970s?) when the kernel's ARG_MAX was small, shells had no auto-completions, and --long-arguments did not exist. Since then better dd remained backward compatible Commented Jan 15, 2016 at 11:43
  • 10
    dd originated from another OS (than UNIX) - a scripting-language (JCL) on IBM's OS/360 - where the conventions were different, before being ported more or less unchanged to UNIX - partly because those likely to use it, knew it from the previous system. Commented Jan 15, 2016 at 12:47

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 ]]
case $key in
    #this is a flag do something here
    #this is a flag do something here
    # this is a key-value parameter
    # the value is always in $2 , 
    # you must shift to skip over for the next iteration
    # unknown option
  • 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.
  • 1
    Well, several GNU utilities (e.g. gcc) handle @mifile.par like your --parfile mifile.par suggestions. Commented Jan 15, 2016 at 12:04
  • 7
    Are you sure about ignoring all other options if there's a parameter file? It sounds counterintuitive to me, at best. Commented Jan 15, 2016 at 14:56
  • 9
    I agree with Jonathan about parameter files. If the parameter file is present, then I would expect it to be used for default values, with arguments given on the command line applied overtop those in the parfile. If for some reason the use of a parfile precludes the use of additional command line arguments, then the presence of additional arguments should be an error. Commented Jan 15, 2016 at 23:12
  • @EldritchCheese In the CLI apps I've written, when a parfile is given, any aditional parameter generates an error. Commented Jan 16, 2016 at 0:04
  • 1
    If using a capable shell, this kind of "config file parameter" option is not necessary. e.g. you just write fooCmd -opt1 -opt2 $(cat more_options.opts). Therefore I would expect a "config file parameter" option, if provided, should basically work in the same way.
    – Brandin
    Commented Jan 16, 2016 at 6:50

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.

  • 1
    I love this answer, and thank you for it, because I am currently frustrated at argparse being none of programmer, user-interface or user friendly.
    – cat
    Commented Jan 15, 2016 at 22:14
  • 1
    I tried docopt, and I don't like it. click results in much cleaner code, although there is a little wonkiness with options when you have subcommands.
    – jpmc26
    Commented Jan 15, 2016 at 23:03
  • 3
    This is too much like an advertisement. Mention the resource just once if it's relevant.. But as it is now, 50% of your answer just sounds like promoting an external resource.
    – Brandin
    Commented Jan 16, 2016 at 6:52
  • 1
    I would word it as 'design the use model first'. Separating the user experience from the functionality can be an artificial distinction in many cases (tool limitations affect the interface).
    – copper.hat
    Commented Jan 16, 2016 at 18:41
  • 1
    +1 for Docopt. It solved all my CLI dilemmas, completely pain free. Sometimes it is hard to tell advertisement from genuine enthusiasm, but here it is - I have been a Docopt enthusiast for years now, not affiliated in any way ;)
    – frnhr
    Commented Jan 21, 2016 at 21:41

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 ?

  • Great, yes! One question is also: can i run ./this-script --hosts < hosts.txt Commented Jan 19, 2016 at 23:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.