The Unix Command Language
The UNIX Command Language
K. Thompson
© K Thompson 1976
Said to have appeared in:
Structured Programming - Infotech State of the Art Report
Nicholson House, Maidenhead, Berkshire, England
Infotech International Ltd. (March 1975), pp. 375-384.
This paper seems like the earliest exposition on a Unix shell, probably the Thompson shell.
Almost all the example Shell (Thompson capitalizes) commands still work,
and work correctly.
You can type ls >output, or date >>output, or ls | pr | lp in 2026,
and they will be valid shell commands, at least in a typical Linux shell
like bash.
There are some oddities to the 21st century eye.
Thompson didn’t write file “paths” as we understand them today,
maybe to avoid having to explain Unix paths in material
where he clearly wanted to focus on the “single notion”
of I/O streams.
That means he used some magic device names,
crd (card reader), lpr (line printer),
lps (printer spooler).
Thompson did not mark program arguments with a -.
One of the pipelines he uses as an example has uniq u
and tp t.
The modern uniq command does by default what Thompson describes uniq u
doing.
The tp command must be an ancestor of the renowned
Unix tar command.
To this day tar accepts an argument of t (no -): tar tf something.tar
is valid usage.
Any streamlining Thompson did was clearly motivated by
wanting to
explain his idea of how useful “streams of bytes” are,
how Unix exploited the idea of files as streams of bytes
to make programming easier.
Thompson emphasizes this in the INTRODUCTION and closing SERMONETTE.
… it is my belief you should base a system on a single notion.
and
… the single notion of I/O steaming and interconnection of utility programs are used to build complex programs…
and
… when future systems are designed by manufacturers, the value of some of these ingrained notions is re-examined.
Philosophy of Shells
I think Thompson informally touches on some areas in the Philosophy of Shells in this paper.
He doesn’t specifically say “shells should use streams of bytes in
both files and I/O” (as opposed to the older “records” based I/O),
but that’s explicitly the “single notion” he explains and gives examples of.
A reader 50 years later can identify the immediate correspondence
of the source | filter | sink notation with conventional use
of file descriptors 0 as stdin, 1 as stdout, and the pipe(2) system call.
Thompson does not try to distinguish a shell’s notion of files and I/O streams,
and the underlying operating system’s notion of files.
Thompson’s Shell has just barely enough flow-of-control constructs
(an if and a goto) to qualify it as a programming language interpreter.
Based only on this paper, it’s hard to say if he thought that was enough,
or if he felt limited by the PDP-11/34 hardware.
At least Thompson feels that it’s important enough to note
what flow-of-control mechanism existed in his Shell,
unlike Louis Pouzin’s RUNCOM
explanation.
As a modern programmer, reading through this type of paper gets me to construct a mental formal grammar as I go. This paper reads as if the Shell had an extremely ad hoc parser.
Typesetting
Given how many of the examples circle around the use of troff and eqn, it seems fitting to note the typesetting of this paper.
Fixed width font, left justified, two spaces after a period.
Words hyphenated properly so that the left justification doesn’t
produce too raggedy of a right margin.
Note that “program” in the example shell pipeline is in an italic font.
I hypothesize this was typeset using nroff
which had appeared in Version 2 Unix, in 1972.
I wish I could see the rest of
Structured Programming - Infotech State of the Art Report
to see how the rest of the volume was typeset.
The use of italics here and there makes me wonder about what
printer Thompson used to render the text.