All our knowledge has its origins in our perceptions.
The interface of a program is the sum of all the ways that it
communicates with human users and other programs. In Chapter10, we discussed the use of environment
variables, switches, run-control files and other parts of
start-up-time interfaces. In this chapter, we'll untangle the history
and explain the pragmatics of Unix interfaces after startup time.
Because user-interface code normally consumes 40% or more of development
time, knowing good design patterns is especially important here in
order to avoid a lot of false starts and time-intensive
In the Unix tradition of interface design, we encounter two
themes over and over again. One is anticipatory design for
communication with other programs; the other is the Rule of Least
Unix programs can give you extra power from being used in
synergistic combinations; we discussed various methods for hooking
together such combinations in Chapter7.
The ‘other programs’ part
of Unix interface design is not an afterthought or a marginal case as
it is under many other operating systems. Rather, it is a central
challenge that has to be balanced and integrated carefully with the
demands of interface design for human users.
Much of Unix-community tradition about program interface design
may seem odd and arbitrary — or even, in the age of the GUI,
downright regressive — when you encounter that tradition for the
first time. But in spite of various blemishes and irregularities,
that tradition has an inner logic to it which is worth learning and
understanding. It reflects heuristics accumulated over Unix's long
history about ways to do effective communication both with human
beings and with other programs. And it includes a set of conventions
which create commonalities between programs — it defines
‘least surprising’ alternatives for a wide range of common
After startup, programs normally get input or commands from the
Data and commands presented on the program's standard
Inputs passed through IPC, such as X server events and
Files and devices in known locations (such as a data file name
passed to or computed by the program).
Programs can emit results in all the same ways (with output
going to standardoutput).
Some Unix programs are graphical, some have screen-oriented
character interfaces, and some use a starkly simple text-filter
design unchanged from the days of mechanical teletypes. To the
uninitiated, it is often far from obvious why any given program
uses the style it does — or, indeed, why Unix supports such a
plethora of interface styles at all.
Unix has several competing interface styles. All are still
alive for a reason; they're optimized for different situations. By
understanding the fit between task and interface style, you will learn
how to choose the right styles for the jobs you need to do.