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