A systematic approach to modern Unix-like command-line interfaces

1. Goals

This approach to parsing command lines also lends itself well to providing command completion and interactive help.

2. Task-specific tool sets

Going from what we already have – the POSIX standard and different approaches to Unix-like command-line interfaces in the wild – the first question that needs to be answered for a systematic approach is what design approach to choose for task-specific tool sets.

It seems that, historically, the phenomenon of task-specific tool sets did not (explicitly) exist on Unix and thus is a relatively new development in command-line utilities on Unix-like systems that is apparently rooted in the need for more powerful/complex tools to do more complex jobs well, such as package management or managing network interfaces. A general desire for a more orderly/structured tool box, where utilities for particular classes of tasks are arranged in some meaningful way, has probably played an equally important role here and is, in fact, intrinsically connected to managing increased complexity.

There are essentially two ways to implement task-specific tool sets:

2.1 Non-hierarchical command sets

One example of this design approach is OpenBSD's tool set for package management. It consists of a collection of four independent utilities (i.e., independent from the user's perspective):

There are two prevalent naming schemes for such command sets:

2.1.1 Advantages

2.1.2 Disadvantages

2.2 Sub-commands

An example of the sub-command approach can be found in Alpine Linux's package manager, apk. Contrary to OpenBSD's pkg_* command set, it offers a set of sub-commands, such as add, del, update, and upgrade that have to be entered as arguments to the apk command, e.g., apk add nano to install the Nano text editor.

2.2.1 Advantages

2.2.2 Disadvantages

3. Utility grammar

3.1 Token classes

Last changed: 2021-08-02

Copyright © 2021 Michael Siegel