Using a Command Language as a High-Level Programming Language
Using a Command Language as a High-Level Programming Language
John R. Mashey
Proc. 2nd Int. Conf. on Software Engineering (October 13-15, 1976), pp. 169-176
It’s my opinion that when Mashey uses “command language”, he’s essentially describing the same thing that’s called a “shell” today. This is an interesting paper for Unix trivia masters. Apart from that, it’s a window into an alternate universe of shell scripting.
This alternate universe has a different style
of assigning to shell variables: = a "something".
The = command seems more general than mere assignment.
Mashey gives examples of piping into a shell variable
(date | = a) and redirecting stdin (= a </dev/tty).
Today, shells like bash
and zsh
have you using the read builtin (date | read a),
or command substitution (a=$(date)).
The pseudo-file /dev/tty existed
even in the faraway time of 1976.
The PWB Unix shell must have done file descriptors
of sub-processes a bit differently than now.
Mashey explains goto and if as separate programs,
and notes how they manipulate file offsets.
He also has an if - then - else - endif construct
as a separate command,
which seems just barely possible.
It might be worthwhile experimenting with a very simple shell,
one with no ; so that commands only occur one per line,
and a goto as a separate program that manipulates file
offset of stdin to see how this happened.
In another aspect of file descriptors being handled differently,
Mashey shows what we now know as “here” documents
without the << MARKER notation.
Mashey describes shell variables in some detail,
as they apparently didn’t occur in Thompson’s shell.
The PWB Unix shell has the
beginnings of standard shell scripting variables like
$?, $PWD, $#.
Something like a PATH environment variable,
but involving a file named .path exists as well.
Operating system internals trivia
Page 2 features a footnote about how the PDP-11 hardware has separate instruction and data address spaces. The text segment of a reentrant program is shared by all processes running that program. “Almost all programs are reentrant”.
Reentrancy is not a property that’s talked about a whole lot these days. It was a big deal when addresses had a 16-bit size limit, and virtual memory was the province of mainframes.
Mashey doesn’t officially define process or program, but he makes a clear distinction between them in this footnote. It looks like his “program” is an executable file, while “process” is the in-memory arrangement of the executable file.
Philosophy of Shells
The introduction of this paper contains a small meditation on “existing CLs” (Command Languages).
Mashey notes that command languages existing in 1976 ranged from “quite similar to assembly languages” to high-level programming languages. He lists some valuable qualities of command languages in bullet points that are entirely material for philosophy of shells:
- Ease of on-line use To Mashey, this is typing commands while sitting at a terminal as opposed to a card punch. Dated, but still worth noting. Perhaps in a modern context, this is the command line vs GUI dichotomy.
- Convenient use of the same language as on-line CL and as a programming language . This seems self-evident today, when even databases with a SQL query language have stored procedures.
- Interchange of programs and CL procedures . Again, programs seem to mean “executable files full of machine code” in this paper. Hard to believe today, but operating systems of yesteryear sometimes made you “run” programs, but “execute” scripts or some such abstract distinction. Also dated but worth noting.
- Ease of creation and maintenance of CL procedures . Mashey wants everyone to be able to whip up cheap-and-dirty little scripts. Mashey aligned with with the “fast - cheap” side of the “good, fast and cheap, pick any two” triangle. Later in the paper, Mashey notes that sometimes popular shell scripts get re-written as compiled C language language programs, to attain extra speed. If you can easily create a script, you can find out what needs more speed.
- Organization of CL procedures . This point is all about sharing scripts between people and organizations.
- “It must be possible to write procedures
with convenient conditional branching, looping,
argument handling, variables, string manipulation,
and occasional arithmetic”.
Here’s where the arguments start.
For example, the PWB Unix shell of this paper
had 26 shell variables, all named with one lower-case letter.
It wasn’t enough. How many is enough,
and in what format should names appear?
Is
onerrortype exception handling of DCL even acceptable, much less sufficient? I could go on. - Separation from operating system . “A CL interpreter should
normally be an ordinary command, treated like other commands,
and definitely not embedded in the heart of the operating system.”
Digital Equipment Corporation violated this at about
the same time this paper was written,
by putting a
DCLinterpreter in every process.
Between “Ease of creation and maintenance” and “an ordinary command”, Mashey seems to be acknowledging Gall’s Law, and that software can evolve rather than be explicitly designed by high priests or other members of the arcanum. I will put it out there that perl 1.0 almost exactly possessed Mashey’s desirable shell features.
Mashey devotes some text to explaining file name generation via globbing, and how this facility saves humans some typing, helps organize files, and promotes the use of large numbers of small files. Features can have the effect of guiding users to do particular things, or use particular styles of interaction without forbidding other styles or uses. This lies at the heart of what features or category(s) of features a shell should possess, and maybe even at the heart of programming language design.
Citations from bibliography
Some of the citations from the bibliography might be interesting from a philosophy of shells viewpoint. They’re typically in in elderly conference proceedings, so they may never make it on to the web, or they may not even exist any more.
Brunt, R. F., and Tuffs, D. E.
A User-Oriented Approach to Control Languages.
Software—Practice and Experience 6, 1 (Jan. 1976), 93-108.
Cowan, R. M.
Burroughs B6700/B7700 Work Flow Language.
Command Languages—Proc. IFIP Working Conference on Command Languages, ed. C. Unger, North Holland, Amsterdam, 1975, 153-66.
Dolotta, T. A., and Irvine, C. A.
Proposal for a Time Sharing Command Structure.
Information Processing 68—Proc. IFIP Congress 1968, vol. 1, North Holland, Amsterdam, 1969, 493-98.
Simpson, D., ed.
Job Control Languages—Past, Present, and Future.
National Computing Centre Ltd., Quay House, Quay St., Manchester, England, 1974.
Unger, C., ed.
Command Languages—Proc. IFIP Working Conference on Command Languages.
North-Holland, Amsterdam, 1975.