[TUHS] evolution of the cli

[Warner Losh via TUHS]

What about the JSON trend. Programs that are complex datasets mediated by
jq.

On Sat, Nov 1, 2025, 10:34 AM Clem Cole via TUHS <tuhs at tuhs.org> wrote:

> Marc, I agree. Like you,  I think Phillips' observations resonate, but you
> nailed it with the drive for higher-level abstractions/being able to do
> more as better automation of a lower-level idea or facility.
>
>
> On Sat, Nov 1, 2025 at 11:57 AM Marc Donner via TUHS <tuhs at tuhs.org>
> wrote:
>
> > 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.
> > >
> >
>