Fixing low command error distances
August 25, 2008
Suppose that you have a command with an unnervingly low error distance, either because a vendor stuck you with it or because it's the natural way to structure the command's arguments. The way to fix this is to change the sort of error required to make a mistake, so that you move from a likely change to an unlikely one.
(If you are working with a vendor command, you will need to do this with some sort of a cover script or program. If you are working with a local command, you can just change the arguments directly.)
For a concrete example, lets look at the ZFS
To make the change less likely, modify the command that the cover script uses to expand a ZFS pool; instead of using 'add' (which is general but raises the question of 'add what?'), use 'grow'. Contrast:
sanpool grow POOL DEVICE sanpool spare POOL DEVICE
Now the commands are fairly strongly distinct and harder to substitute for each other, because it is a much bigger mental distance from 'add a spare' to 'grow the pool' than from 'add a spare' to 'add a device'.
(When trying to prevent errors, it is useful to approach the commands from a high level view of what people are trying to do rather than look for low-level similarities in how it gets done. In a sense the way to avoid errors is to avoid similarities in things that are actually different.)
Another other way for cover scripts to help you avoid errors is to
just not allow them to start with. System commands may have to be
general and thus allow even the questionable, but your scripts can
be more restrictive; for example, if you know you should never have
non-redundant ZFS pool devices, you can just make '
Written on 25 August 2008.
* * *
Atom feeds are available; see the bottom of most pages.