This is just a quick question about standard CLI-parsing design.

Say we have:

foo -abc 

for most CLI-parsers, a single - dash (as opposed to a double dash --) means you can group single letter options together. Such that the above is synonymous with:

foo -a -b -c

my question is - for grouping, is it possible or advisable to group non-boolean options? To me it seems like boolean options/switches are the only kind of options that can be grouped without confusing/unpredictable behavior.


It's quite common to add a non-boolean option at the end of a group of boolean options, like:

git commit -am "My commit message"

Otherwise, your assessment is spot on.

  • nice, that makes sense, it is a little confusing though. So the last letter in a group is permitted to be a non-boolean? – MrCholo Sep 5 '18 at 4:45
  • 1
    This would only work if one of the grouped options required a parameter. Otherwise this would be ambiguous what followed. I would probably just decide at that point which non-boolean option is less used and require it to be specified outside the group (otherwise, good luck explainng that to the client). – Neil Sep 5 '18 at 8:24
  • Theoretically, you could freely intermix as many flags and options requiring parameters as you want, as long as you specify unambiguously what they mean. For example, you could specify that the arguments following the group are bound to the parameters in the order that they appear in the group. There are really two questions you have to ask: can I do it? (Can I find a unambiguous specification, such that the computer can understand it?) And should I do it? (Can I find an understandable, simple explanation such that the user can understand it?) – Jörg W Mittag Sep 5 '18 at 10:39
  • 1
    In other words, to use the exact words that you used in your question: "possible" and "advisable" are really two different questions. – Jörg W Mittag Sep 5 '18 at 10:40
  • Well theoretically, you could intermix as many flags and options requiring parameters as you want, ambiguous or otherwise. I think the goal here is to make it easy to use, and that has to take priority over any other decision here, regardless of feasibility. – Neil Sep 5 '18 at 13:25

It depends on the program. There is actually no universal answer to your question.

CLI-parsing is entirely done by the program, often using getopt or getopts, but not always. For example, the find command arguments all use the single-dash prefix but none are actually groupable. (This convention has been discouraged for quite awhile.)

Many modern programs have done away with the single-dash option prefix entirely. It ultimately takes a lot of code (such as encapsulated in getopt/getopts) to handle all the permutations and is the antithesis of "self documenting code".

The double-dash prefix, which never allows grouping, is far simpler to parse and is far more self-documenting since it promotes spelling out the option, or at least a common abbreviation for it.

So too, the greater number of keystrokes is not really an issue anymore, as all common shells support pressing the up-arrow to present previous command lines and Ctrl-r to search those previous lines, which can then be edited. Thus, the full command string only has to be entered once. In addition, most command line work is done through terminal programs these days so mouse copy-n-paste of the history command output is also available.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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