4

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.

2 Answers2

4

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • nice, that makes sense, it is a little confusing though. So the last letter in a group is permitted to be a non-boolean? –  Sep 05 '18 at 04: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 05 '18 at 08: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 05 '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 05 '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 05 '18 at 13:25
  • I think it's pretty clear that only one letter can take input, and it makes sense for it to be the last one, as a convention. But you could design a CLI, where only one letter could take input, but that letter could be in any position in the group, aka `git commit -ma "My commit message"`, but I think that is bad design, because you get weird unrecognizable/uncommon combos. –  Sep 06 '18 at 03:02
0

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

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

DocSalvager
  • 305
  • 2
  • 8