2020-08-05
My views on some conventions for Unix command line options
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.)
We may wind up significantly delaying or mostly skipping Ubuntu 20.04
Back at the start of April, I wrote about how we might face some issues with the timing of Ubuntu 20.04, given ongoing world and local events, because we generally need to be in the office to deploy 20.04 machines and upgrade machines to 20.04. Back then, I optimistically hoped for a return to normality and the office perhaps by July, and in any case not lots and lots later. That is not the situation we've wound up in. Instead, it seems most likely that we won't be in the office on regular basis until next spring at the earliest.
The highest priority machines to upgrade are our remaining Ubuntu 16.04 machines, which will be going out of support in April of next year. Fortunately we don't have very many of them compared to our 18.04 machines, so there is not a huge amount of work to do. Unfortunately, most of our Exim based mail machines are 16.04 and the 20.04 version of Exim is a significantly disruptive upgrade, plus a number of the remaining machines are delicate to upgrade (our Samba server, for example).
This opens up the issue of what Ubuntu version to upgrade these 16.04 machines to. Normally we'd upgrade them to Ubuntu 20.04, but normally we'd already be running less critical machines on 20.04 and getting experience with it; this time they'd be among our first 20.04 machines. On the other side, we're already running Ubuntu 18.04 in general and in some cases running the same services on 18.04 as we currently do on 16.04 (we have a couple of 18.04 Exim machines, for example). This makes upgrading most or all of our 16.04 machines to 18.04 instead of 20.04 a reasonably attractive proposition, especially for Exim based machines. We'd have to upgrade them again in two years when 22.04 comes out and 18.04 starts going out of support, but hopefully in two years the situation will be a lot different.
(If we're not back in the office in two years, it seems likely that a fair number of things will have changed in our operations. And in any case we'll have a lot more experience with remote operation, and possibly hardware that better supports it.)
If we only have limited time in the office to work on machines, going out of our way to upgrade 18.04 machines to 20.04 seems like a bad use of time, even if they're machines that we normally try to keep on the latest version of Ubuntu (such as our user login servers). There will be new machines and there are some machines where we want to rework them anyway for various reasons, and both of these may sensibly wind up on 20.04, but otherwise I suspect we're going to leave more machines than usual at 18.04 until we're back in the office.
(New services can go on Ubuntu 20.04 without causing any extra problems, because we'd have to develop and explore them no matter what Ubuntu version we used for them.)
If we get back in the office on an ongoing basis next summer, we could start upgrading machines to Ubuntu 20.04 then, but Ubuntu 22.04 will be only a year away. We may well decide to stick with 18.04 for most machines and move them to 22.04 when it comes out.
Overall this seems likely to leave us with relatively modest use of Ubuntu 20.04, although we're definitely planning to use it for some things. To the extent that we do use Ubuntu 20.04, our use is going to be slow and delayed (and has already been delayed from our usual timeline).