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 three ways to implement task-specific tool sets:

2.1 Structured command-line options

A tool that needs to perfom several distinct tasks, e.g., installing and removing software packages could simply utilize command-line options to denote the respective operation (“sub-command”). Doing that would, however, require dividing its options into three distinct categories:

Example: pacman capital letters for operations

2.1.1 Advantages

2.1.2 Disadvantages

Implementing sub-commands as options, i.e., not keeing sub-commands and options strictly separate syntactically, creates a user interface that is slightly harder to use because options can not be given in random order anymore because some options denote commands. One way to partly mitigate this would be to allow global options to occur among command-specific ones. E.g., if a tool has the option `-v` for verbose output, then

should yield the same result, i.e., the meaning of -v should be exactly the same in both cases: Generally be verbose. This would also be advisable for the approach of using actual sub-commands. Non-hierarchical command sets need to have that ability per se, if there are any global options.

2.2 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.2.1 Advantages

2.2.2 Disadvantages

2.3 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.3.1 Advantages

2.3.2 Disadvantages

3. Utility grammar

3.1 Token classes

Last changed: 2022-01-02

Copyright © 2021, 2022 Michael Siegel