flak rss random

changing defaults and removing options

Times change and programs must change with them. Altering or removing functionality however risks breaking backwards compatibility. A few examples.


Everybody’s favorite terminal locker, lock, had a default timeout of 15 minutes, after which it would autounlock. Probably a reasonable behavior when you’d have students in the lab getting distracted and running out to the see the latest Molly Ringwald film, and then nobody could access that terminal until (if) they returned. In the modern era, it makes more sense to lock until the operator returns. And thus was the default behavior belatedly changed to make -n the default. And then remove the now useless option.

Alas, what about the users who were already using -n? Now they receive an error. And no locking. Easy to miss if you’re using a hotkey or a script. The user intention is clear, a lock with no timeout, and so the option was restored.


The reverse situation, removing functionality without changing the default. We are tired of timezone support in the kernel, and peeling this back requires removing it from the the userland utilities that support it, such as date. Here’s a diff for date. As proposed, we keep the options for compatibility. But they no longer do anything.

In contrast to the previous example, the operator using these options will not get what they want. In this case the option should be removed entirely, to generate errors, because the requested and expected behavior is not available.


Long ago, apmd had both -A and -C options with slightly different semantics. The internal operations were reworked quite a bit, and the second option subsumed by the first. Everybody now gets the best of both worlds. One could remove the now useless option, but anyone who configured a system long ago may still be using -C. Again, the intention is clear and generating an error probably won’t make anybody happier.


Similarly, install has an -S option for a safe copy. This was made the default, but the option is retained. Relevant mail thread.


Sometimes we will want to remove an option. Especially in programs that have too many options, like ls or ps. Or grep. It’s very difficult to add options for cool new features when all the good letters are taken.

grep used to have some symlink traversal options like -H, duplicating functionality better left to find, which were removed. A year later, the -H option comes back with a different meaning.

It would have been confusing and potentially disruptive to switch the behavior all at once. But clearing house let’s us repurpose the option letter later.


Try not to break too much. This must be weighed against the potential use of the option later. Some programs have a greater alphabet hunger than others. If it’s likely we will want to recycle the option, better to remove it entirely for some time. If leaving the option in place won’t be a problem, it’s possible to leave it in place forever. Most importantly, consider user intent. Redundant, but unambiguous, commands are fine.

Posted 08 Aug 2019 18:14 by tedu Updated: 08 Aug 2019 18:53
Tagged: openbsd programming