My views on some conventions for Unix command line options

August 5, 2020

Recently I read Chris Wellons' Conventions for Command Line Options, which reviews these conventions. As it happens, I learned and have internalized a somewhat different version of how these conventions should be and how I expect programs to behave. I'm not going to mention things where my expectations agree with Wellons' presentation of the conventions, just where I differ.

On short options that accept an argument, Wellons says:

This technique is used to create another category, optional option arguments. The option’s argument can be optional [...]

There are no optional option arguments; an option either always takes an argument or it never does. This is how the traditional getopt(3) behaves, at least as far as I remember, and appears to be how the 4.3 BSD getopt(3) manpage documents it.

(It's also how POSIX getopt() is required to behave; see the discussion of how optarg is set.)

Options can typically appear in any order — something parsers often achieve via permutation — but non-options typically follow options.

Non-options always follow options. By extension, the first non-option argument terminates scanning for options; any remaining '-...' things become arguments. Again this is how the 4.3 BSD getopt(3) is documented, and in fact that options and non-options can't be intermixed is mostly required by the getopt(3) API.

(How getopt(3) returns non-option arguments to you is that it gives you the index of the first argument in argv. To support intermixed options and non-options, it would have to permute the order of entries in argv to move all options up to before all non-options. In modern C definitions of getopt(3), including the POSIX one, I believe this is forbidden because argv is declared const.)

My strong cultural expectations for option handling only cover short options; while I have opinions about how long options should act, they're not as visceral as for short options. Just as with short options and for much the same pragmatic reasons, I don't believe in long options with optional option arguments; long options should either always take an argument or never do so. Behaving otherwise breaks my expectation that long options are just the same as short options except longer (and they can't be grouped, and there's that optional '=' thing for arguments).

(This difference between my views and Chris Wellons' views points out some general issues here, but that's for another entry.)


Comments on this page:

By nanaya at 2020-08-06 00:55:16:

The optional option argument is especially annoying in gnu sed. In there it behaves unlike any other options.

By John Wiersba at 2020-08-06 16:33:10:

See (GNU) man getopt for the GNU take on argument shuffling and POSIX compatibility pertaining to this topic. See Stéphane's answer at https://unix.stackexchange.com/a/224451/42620 for a discussion of different option parsing styles.

Personally, I find optional option arguments error-prone and avoid using them or depending on them as much as possible. One common example of an optional option argument is sed -i[SUFFIX] (edit-in-place with optional backup).

Related and possibly useful:

As far as optional option-arguments are concerned, the POSIX Utility Syntax Guidelines say:

Option-arguments should not be optional.

Written on 05 August 2020.
« We may wind up significantly delaying or mostly skipping Ubuntu 20.04
Our problem installing an old Ubuntu kernel set of packages »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Aug 5 23:34:11 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.