[TUHS] evolution of the cli

[Marc Donner via TUHS]

A lot of what you say is appealing and resonates with me.

Let me offer another dimension to help think about the evolution of CLI
goodies: automation.

In the early days of the Arpanet we got a wonderful ability - transfer a
file from one computer to another without writing a tape and making a trip
to the post office.  FTP was wonderful.  With administrative coherence we
also got smoother integration with tools like rcp.

Along with these things came rapid growth in the number of machines in a
domain and the need to manage them coherently.  Now we needed to transfer a
bunch of files to a bunch of different machines.  Enter rdist.  (We will
leave the security challenges to the side.).  Suddenly we could establish a
common system image for a large number of machines.

We then discovered that not all machines should be absolutely identical, so
we layered all sorts of machinery on top of rdist and its multifarious
descendants so that we could keep various subtrees coherent.

What we ended up with is a growing set of layered abstractions.  At the
bottom were some fairly simple pieces of machinery that did this or that on
the bare OS.  Next were a collection of abstractions that automated the
orchestration of these underlying bits.  Some of these abstractions turned
out to be seminal innovations in and of themselves and were then used in
developing yet another tier of abstractions and automations on top of the
second tier.

As time passed we layered more and more abstractions.

Of course, from time to time we also looked at the chaotic pile of
abstractions and attempted to streamline and simplify them, with varying
levels of success.

Best,

Marc
=====
mindthegapdialogs.com <https://www.mindthegapdialogs.com>
north-fork.info <https://www.north-fork.info>


On Sat, Nov 1, 2025 at 10:59 AM A. P. Garcia via TUHS <tuhs at tuhs.org> wrote:

> i'm a bit reluctant to post this here lest you rip it apart, but i'm guess
> i'm ok with that if it happens. i'm more interested in learning the truth
> than i am in being right.
>
> The Evolution of the Command Line: From Terseness to Expression
>
> 1. The Classical Unix Model (1970s–80s)
>
> cmd -flags arguments
>
> The early Unix commands embodied the ideal of “do one thing well.” Each
> flag was terse and mnemonic (-l, -r), and each utility was atomic. The
> shell provided composition through pipes. Commands like grep, cut, and sort
> combined to perform a series of operations on the same data stream.
>
> 2. The GNU Era (late 80s–90s)
>
> cmd --long-simple --long-key=value [arguments]
>
> The GNU Project introduced long options to help people remember what the
> terse flags meant. Common options like --help and --version made tools
> self-describing.
>
> Strengths: clarity, accessibility, scriptability
> Weaknesses: creeping featurism
>
> 3. The “Swiss Army Knife” Model (1990s–2000s)
>
> Next was consolidation. Developers shipped a single binary with multiple
> subcommands:
>
> command subcommand [options] [arguments]
>
> Example: openssl x509 -in cert.pem -noout -text
>
> Each subcommand occupied its own domain, effectively creating namespaces.
> This structure defined tools like git, svn, and openssl.
>
> Strengths: unified packaging, logical grouping
> Weaknesses: internal inconsistency; subcommands evolved unevenly.
>
> 4. The Verb-Oriented CLI (2000s–Present)
>
> As CLIs matured, their design grew more linguistic. Tools like Docker, Git,
> and Kubernetes introduced verb-oriented hierarchies:
>
> tool verb [object] [flags]
>
> Example: docker run -it ubuntu bash
>
> This mapped naturally to the mental model of performing actions: “Docker,
> run this container.” “Git, commit this change.” Frameworks like Go’s Cobra
> or Python’s Click standardized the pattern.
>
> Strengths: extensible, discoverable, self-documenting
> Weaknesses: verbosity and conceptual overhead. A CLI became an ecosystem.
>
> 5. The Sententious Model
>
> When a domain grows too complex for neat hierarchies, a single command
> becomes a compact expression of a workflow. Consider zfs, an elegant
> example of declarative-imperative blending:
>
> zfs create -o compression=lz4 tank/data
> It reads almost like a sentence:
>
> “Create a new dataset called tank/data with compression enabled using LZ4.”
>
> Each option plays a grammatical role:
>
> create — the verb
> -o compression=lz4 — a property or adverbial modifier
> tank/data — the object being acted upon
>
> One fluent expression defines what and how. The syntax is a kind of
> expressive and efficient shell-native DSL.
>
> This phase of CLI design is baroque: not minimalist, not verbose, but
> literary in its compression of meaning.
>
> 6. The Configuration-Driven CLI (Modern Era)
>
> Example: kubectl apply -f deployment.yaml
>
> Today’s tools often speak in declarative terms. Rather than specify every
> step, you provide a desired state in a file, and the CLI enacts it.
>
> Strengths: scales elegantly in automation, integrates with APIs
> Weaknesses: less immediacy; the human feedback loop grows distant.
>
> Across half a century of design, the command line has evolved from terse
> incantations to expressive languages of intent.
>