1.

Introduction

There have been three versions of UNIX. The earliest

version (circa 1969–70) ran on the Digital Equipment Cor-
poration PDP-7 and -9 computers. The second version ran
on the unprotected PDP-11/20 computer. This paper
describes only the PDP-11/40 and /45 [l] system since it is
The UNIX Time- more modern and many of the differences between it and

Sharing System older UNIX systems result from redesign of features found
to be deficient or lacking.
Since PDP-11 UNIX became operational in February
Dennis M. Ritchie and Ken Thompson 1971, about 40 installations have been put into service; they
are generally smaller than the system described here. Most
Bell Laboratories of them are engaged in applications such as the preparation
and formatting of patent applications and other textual
material, the collection and processing of trouble data from
various switching machines within the Bell System, and
recording and checking telephone service orders. Our own
installation is used mainly for research in operating sys-
tems, languages, computer networks, and other topics in
computer science, and also for document preparation.
UNIX is a general-purpose, multi-user, interactive
Perhaps the most important achievement of UNIX is to
operating system for the Digital Equipment Corpora- demonstrate that a powerful operating system for interac-
tion PDP-11/40 and 11/45 computers. It offers a number tive use need not be expensive either in equipment or in
of features seldom found even in larger operating sys- human effort: UNIX can run on hardware costing as little as
tems, including: (1) a hierarchical file system incorpo- $40,000, and less than two man years were spent on the
rating demountable volumes; (2) compatible file, device, main system software. Yet UNIX contains a number of fea-
and inter-process I/O; (3) the ability to initiate asynchro- tures seldom offered even in much larger systems. It is
nous processes; (4) system command language select- hoped, however, the users of UNIX will find that the most
able on a per-user basis; and (5) over 100 subsystems important characteristics of the system are its simplicity,
including a dozen languages. This paper discusses the elegance, and ease of use.
nature and implementation of the file system and of the Besides the system proper, the major programs avail-
user command interface. able under UNIX are: assembler, text editor based on QED
Key Words and Phrases: time-sharing, operating [2], linking loader, symbolic debugger, compiler for a lan-
system, file system, command language, PDP-11 guage resembling BCPL [3] with types and structures (C),
CR Categories: 4.30, 4.32 interpreter for a dialect of BASIC, text formatting program,
Fortran compiler, Snobol interpreter, top-down compiler-
compiler (TMG) [4], bottom-up compiler-compiler (YACC),
form letter generator, macro processor (M6) [5], and per-
muted index program.
There is also a host of maintenance, utility, recreation,
and novelty programs. All of these programs were written
locally. It is worth noting that the system is totally self-sup-
porting. All UNIX software is maintained under UNIX; like-
Copyright © 1974, Association for Computing Machinery,
wise, UNIX documents are generated and formatted by the
Inc. General permission to republish, but not for profit, all or part
of this material is granted provided that ACM’s copyright notice is UNIX editor and text formatting program.
given and that reference is made to the publication, to its date of
issue, and to the fact that reprinting privileges were granted by
permission of the Association for Computing Machinery.
This is a revised version of a paper presented at the Fourth 2. Hardware and Software Environment
ACM Symposium on Operating Systems Principles, IBM Thomas
J. Watson Research Center, Yorktown Heights. New York, Octo- The PDP-11/45 on which our UNIX installation is imple-
ber 15–17, 1973. Authors’ address: Bell Laboratories, Murray mented is a 16-bit word (8-bit byte) computer with 144K
Hill, NJ 07974. bytes of core memory; UNIX occupies 42K bytes. This sys-
The electronic version was recreated by Eric A. Brewer, Uni-
versity of California at Berkeley, [email protected]. Please
tem, however, includes a very large number of device driv-
notify me of any deviations from the original; I have left errors in ers and enjoys a generous allotment of space for I/O buffers
the original unchanged. and system tables; a minimal system capable of running the

365 Electronic version recreated by Eric A. Brewer Communications July 1974

University of California at Berkeley of Volume 17
the ACM Number 7
software mentioned above can require as little as 50K bytes own files; he may also create subdirectories to contain
of core altogether. groups of files conveniently treated together. A directory
The PDP-11 has a 1M byte fixed-head disk, used for file behaves exactly like an ordinary file except that it cannot be
system storage and swapping, four moving-head disk drives written on by unprivileged programs, so that the system
which each provide 2.5M bytes on removable disk car- controls the contents of directories. However, anyone with
tridges, and a single moving-head disk drive which uses appropriate permission may read a directory just like any
removable 40M byte disk packs. There are also a high- other file.
speed paper tape reader-punch, nine-track magnetic tape, The system maintains several directories for its own
and D-tape (a variety of magnetic tape facility in which use. One of these is the root directory. All files in the sys-
individual records may be addressed and rewritten). tem can be found by tracing a path through a chain of direc-
Besides the console typewriter, there are 14 variable-speed tories until the desired file is reached. The starting point for
communications interfaces attached to 100-series datasets such searches is often the root. Another system directory
and a 201 dataset interface used primarily for spooling contains all the programs provided for general use; that is,
printout to a communal line printer. There are also several all the commands. As will be seen however, it is by no
one-of-a-kind devices including a Picturephone® interface, means necessary that a program reside in this directory for
a voice response unit, a voice synthesizer, a phototypesetter, it to be executed.
a digital switching network, and a satellite PDP-11/20 which Files are named by sequences of 14 or fewer charac-
generates vectors, curves, and characters on a Tektronix 611 ters. When the name of a file is specified to the system, it
storage-tube display. may be in the form of a path name, which is a sequence of
The greater part of UNIX software is written in the directory names separated by slashes “/” and ending in a
above-mentioned C language [6]. Early versions of the file name. If the sequence begins with a slash, the search
operating system were written in assembly language, but begins in the root directory. The name /alpha/beta/gamma
during the summer of 1973, it was rewritten in C. The size causes the system to search the root for directory alpha,
of the new system is about one third greater than the old. then to search alpha for beta, finally to find gamma in beta.
Since the new system is not only much easier to understand Gamma may be an ordinary file, a directory, or a special
and to modify but also includes many functional improve- file. As a limiting case, the name “/” refers to the root itself.
ments, including multiprogramming and the ability to share A path name not starting with “/” causes the system to
reentrant code among several user programs, we considered begin the search in the user’s current directory. Thus, the
this increase in size quite acceptable. name alpha/beta specifies the file named beta in subdirec-
tory alpha of the current directory. The simplest kind of
name, for example alpha, refers to a file which itself is
found in the current directory. As another limiting case, the
3. The File System
null file name refers to the current directory.
The most important job of UNIX is to provide a file sys- The same nondirectory file may appear in several
tem. From the point of view of the user, there are three directories under possibly different names. This feature is
kinds of files: ordinary disk files, directories, and special called linking; a directory entry for a file is sometimes
files. called a link. UNIX differs from other systems in which link-
ing is permitted in that all links to a file have equal status.
3.1 Ordinary Files That is, a file does not exist within a particular directory;
A file contains whatever information the user places on the directory entry for a file consists merely of its name and
it, for example symbolic or binary (object) programs. No a pointer to the information actually describing the file.
particular structuring is expected by the system. Files of Thus a file exists independently of any directory entry,
text consist simply of a string of characters, with lines although in practice a file is made to disappear along with
demarcated by the new-line character. Binary programs are the last link to it.
sequences of words as they will appear in core memory Each directory always has at least two entries. The
when the program starts executing. A few user programs name in each directory refers to the directory itself. Thus a
manipulate files with more structure: the assembler gener- program may read the current directory under the name “.”
ates and the loader expects an object file in a particular for- without knowing its complete path name. The name “..” by
mat. However, the structure of files is controlled by the convention refers to the parent of the directory in which it
programs which use them, not by the system. appears, that is, to the directory in which it was created.
The directory structure is constrained to have the form
3.2 Directories of a rooted tree. Except for the special entries “.” and “..”,
Directories provide the mapping between the names of each directory must appear as an entry in exactly one other,
files and the files themselves, and thus induce a structure on which is its parent. The reason for this is to simplify the
the file system as a whole. Each user has a directory of his writing of programs which visit subtrees of the directory

366 Electronic version recreated by Eric A. Brewer Communications July 1974

University of California at Berkeley of Volume 17
the ACM Number 7
structure, and more important, to avoid the separation of particular, in the root directories of all file systems, remov-
portions of the hierarchy. If arbitrary links to directories able or not, the name “..” refers to the directory itself
were permitted, it would be quite difficult to detect when instead of to its parent.
the last connection from the root to a directory was severed.
3.5 Protection
3.3 Special Files Although the access control scheme in UNIX is quite
Special files constitute the most unusual feature of the simple, it has some unusual features. Each user of the sys-
UNIX file system. Each I/O device supported by UNIX is tem is assigned a unique user identification number. When
associated with at least one such file. Special files are read a file is created, it is marked with the user ID of its owner.
and written just like ordinary disk files, but requests to read Also given for new files is a set of seven protection bits. Six
or write result in activation of the associated device. An of these specify independently read, write, and execute per-
entry for each special file resides in directory /dev, although mission for the owner of the file and for all other users.
a link may be made to one of these files just like an ordi- If the seventh bit is on, the system will temporarily
nary file. Thus, for example, to punch paper tape, one may change the user identification of the current user to that of
write on the file /dev/ppt. Special files exist for each com- the creator of the file whenever the file is executed as a pro-
munication line, each disk, each tape drive, and for physical gram. This change in user ID is effective only during the
core memory. Of course, the active disks and the core spe- execution of the program which calls for it. The set-user-ID
cial file are protected from indiscriminate access. feature provides for privileged programs which may use
There is a threefold advantage in treating I/O devices files inaccessible to other users. For example, a program
this way: file and device I/O are as similar as possible; file may keep an accounting file which should neither be read
and device names have the same syntax and meaning, so nor changed except by the program itself. If the set-user-
that a program expecting a file name as a parameter can be identification bit is on for the program, it may access the
passed a device name; finally, special files are subject to the file although this access might be forbidden to other pro-
same protection mechanism as regular files. grams invoked by the given program’s user. Since the
actual user ID of the invoker of any program is always
3.4 Removable File Systems available, set-user-ID programs may take any measures
Although the root of the file system is always stored on desired to satisfy themselves as to their invoker’s creden-
the same device, it is not necessary that the entire file sys- tials. This mechanism is used to allow users to execute the
tem hierarchy reside on this device. There is a mount sys- carefully written commands which call privileged system
tem request which has two arguments: the name of an entries. For example, there is a system entry invocable only
existing ordinary file, and the name of a direct-access spe- by the “super-user” (below) which creates an empty direc-
cial file whose associated storage volume (e.g. disk pack) tory. As indicated above, directories are expected to have
should have the structure of an independent file system con- entries for “.” and “..”. The command which creates a direc-
taining its own directory hierarchy. The effect of mount is to tory is owned by the super user and has the set-user-ID bit
cause references to the heretofore ordinary file to refer set. After it checks its invoker’s authorization to create the
instead to the root directory of the file system on the remov- specified directory, it creates it and makes the entries for “.”
able volume. In effect, mount replaces a leaf of the hierar- and “..”.
chy tree (the ordinary file) by a whole new subtree (the Since anyone may set the set-user-ID bit on one of his
hierarchy stored on the removable volume). After the own files, this mechanism is generally available with- out
mount, there is virtually no distinction between files on the administrative intervention. For example, this protection
removable volume and those in the permanent file system. scheme easily solves the MOO accounting problem posed in
In our installation, for example, the root directory resides [7].
on the fixed-head disk, and the large disk drive, which con- The system recognizes one particular user ID (that of
tains user’s files, is mounted by the system initialization the “super-user”) as exempt from the usual constraints on
program, the four smaller disk drives are available to users file access; thus (for example) programs may be written to
for mounting their own disk packs. A mountable file system dump and reload the file system without unwanted interfer-
is generated by writing on its corresponding special file. A ence from the protection system.
utility program is available to create an empty file system,
or one may simply copy an existing file system. 3.6 I/O Calls
There is only one exception to the rule of identical The system calls to do I/O are designed to eliminate the
treatment of files on different devices: no link may exist differences between the various devices and styles of
between one file system hierarchy and another. This restric- access. There is no distinction between “random” and
tion is enforced so as to avoid the elaborate bookkeeping sequential I/O, nor is any logical record size imposed by the
which would otherwise be required to assure removal of the system. The size of an ordinary file is determined by the
links when the removable volume is finally dismounted. In

367 Electronic version recreated by Eric A. Brewer Communications July 1974

University of California at Berkeley of Volume 17
the ACM Number 7
highest byte written on it; no predetermination of the size of Up to count bytes are transmitted between the file specified
a file is necessary or possible. by filep and the byte array specified by buffer. The returned
To illustrate the essentials of I/O in UNIX, Some of the value n is the number of bytes actually transmitted. In the
basic calls are summarized below in an anonymous lan- write case, n is the same as count except under exceptional
guage which will indicate the required parameters without conditions like I/O errors or end of physical medium on spe-
getting into the complexities of machine language program- cial files; in a read, however, n may without error be less
ming. Each call to the system may potentially result in an than count. If the read pointer is so near the end of the file
error return, which for simplicity is not represented in the that reading count characters would cause reading beyond
calling sequence. the end, only sufficient bytes are transmitted to reach the
To read or write a file assumed to exist already, it must end of the file; also, typewriter-like devices never return
be opened by the following call: more than one line of input. When a read call returns with n
equal to zero, it indicates the end of the file. For disk files
filep = open (name, flag)
this occurs when the read pointer becomes equal to the cur-
Name indicates the name of the file. An arbitrary path name rent size of the file. It is possible to generate an end-of-file
may be given. The flag argument indicates whether the file from a typewriter by use of an escape sequence which
is to be read, written, or “updated”, that is read and written depends on the device used.
simultaneously. Bytes written on a file affect only those implied by the
The returned value filep is called a file descriptor. It is position of the write pointer and the count; no other part of
a small integer used to identify the file in subsequent calls the file is changed. If the last byte lies beyond the end of the
to read, write, or otherwise manipulate it. file, the file is grown as needed.
To create a new file or completely rewrite an old one, To do random (direct access) I/O, it is only necessary to
there is a create system call which creates the given file if it move the read or write pointer to the appropriate location in
does not exist, or truncates it to zero length if it does exist. the file.
Create also opens the new file for writing and, like open,
location = seek(filep, base, offset)
returns a file descriptor.
There are no user-visible locks in the file system, nor is The pointer associated with filep is moved to a position off-
there any restriction on the number of users who may have set bytes from the beginning of the file, from the current
a file open for reading or writing; although it is possible for position of the pointer, or from the end of the file, depend-
the contents of a file to become scrambled when two users ing on base. Offset may be negative. For some devices (e.g.
write on it simultaneously, in practice, difficulties do not paper tape and typewriters) seek calls are ignored. The
arise. We take the view that locks are neither necessary nor actual offset from the beginning of the file to which the
sufficient, in our environment, to prevent interference pointer was moved is returned in location.
between users of the same file. They are unnecessary 3.6.1 Other I/O Calls. There are several additional sys-
because we are not faced with large, single-file data bases tem entries having to do with I/O and with the file system
maintained by independent processes. They are insufficient which will not be discussed. For example: close a file, get
because locks in the ordinary sense, whereby one user is the status of a file, change the protection mode or the owner
prevented from writing on a file which another user is read- of a file, create a directory, make a link to an existing file,
ing, cannot prevent confusion when, for example, both delete a file.
users are editing a file with an editor which makes a copy of
the file being edited.
It should be said that the system has sufficient internal 4. Implementation of the File System
interlocks to maintain the logical consistency of the file sys-
tem when two users engage simultaneously in such incon- As mentioned in §3.2 above, a directory entry contains
venient activities as writing on the same file, creating files only a name for the associated file and a pointer to the file
in the same directory or deleting each other’s open files. itself. This pointer is an integer called the i-number (for
Except as indicated below, reading and writing are index number) of the file. When the file is accessed, its i-
sequential. This means that if a particular byte in the file number is used as an index into a system table (the i-list)
was the last byte written (or read), the next I/O call implic- stored in a known part of the device on which the directory
itly refers to the first following byte. For each open file resides. The entry thereby found (the file’s i-node) contains
there is a pointer, maintained by the system, which indi- the description of the file as follows.
cates the next byte to be read or written. If n bytes are read 1. Its owner.
or written, the pointer advances by n bytes. 2. Its protection bits.
Once a file is open, the following calls may be used: 3. The physical disk or tape addresses for the file
n = read(filep, buffer, count) contents.
n = write(filep, buffer, count) 4. Its size.

368 Electronic version recreated by Eric A. Brewer Communications July 1974

University of California at Berkeley of Volume 17
the ACM Number 7
5. Time of last modification directory on all file systems), and the device name is
6. The number of links to the file, that is, the number of replaced by the table value.
times it appears in a directory. To the user, both reading and writing of files appear to
7. A bit indicating whether the file is a directory. be synchronous and unbuffered. That is immediately after
8. A bit indicating whether the file is a special file. return from a read call the data are available, and con-
9. A bit indicating whether the file is “large” or “small.” versely after a write the user’s workspace may be reused. In
fact the system maintains a rather complicated buffering
The purpose of an open or create system call is to turn the
mechanism which reduces greatly the number of I/O opera-
path name given by the user into an i-number by searching
tions required to access a file. Suppose a write call is made
the explicitly or implicitly named directories. Once a file is
specifying transmission of a single byte.
open, its device, i-number, and read/write pointer are stored
UNIX will search its buffers to see whether the affected
in a system table indexed by the file descriptor returned by
disk block currently resides in core memory; if not, it will
the open or create. Thus the file descriptor supplied during
be read in from the device. Then the affected byte is
a subsequent call to read or write the file may be easily
replaced in the buffer, and an entry is made in a list of
related to the information necessary to access the file.
blocks to be written. The return from the write call may
When a new file is created, an i-node is allocated for it
then take place, although the actual I/O may not be com-
and a directory entry is made which contains the name of
pleted until a later time. Conversely, if a single byte is read,
the file and the i-node number. Making a link to an existing
the system determines whether the secondary storage block
file involves creating a directory entry with the new name,
in which the byte is located is already in one of the system’s
copying the i-number from the original file entry, and incre-
buffers; if so, the byte can be returned immediately. If not,
menting the link-count field of the i-node. Removing
the block is read into a buffer and the byte picked out.
(deleting) a file is done by decrementing the link-count of
A program which reads or writes files in units of 512
the i-node specified by its directory entry and erasing the
bytes has an advantage over a program which reads or
directory entry. If the link-count drops to 0, any disk blocks
writes a single byte at a time, but the gain is not immense; it
in the file are freed and the i-node is deallocated.
comes mainly from the avoidance of system overhead. A
The space on all fixed or removable disks which con-
program which is used rarely or which does no great vol-
tain a file system is divided into a number of 512-byte
ume of I/O may quite reasonably read and write in units as
blocks logically addressed from 0 up to a limit which
small as it wishes.
depends on the device. There is space in the i-node of each
The notion of the i-list is an unusual feature of UNIX. In
file for eight device addresses. A small (nonspecial) file fits
practice, this method of organizing the file system has
into eight or fewer blocks; in this case the addresses of the
proved quite reliable and easy to deal with. To the system
blocks themselves are stored. For large (nonspecial) files,
itself, one of its strengths is the fact that each file has a
each of the eight device addresses may point to an indirect
short, unambiguous name which is related in a simple way
block of 256 addresses of blocks constituting the file itself.
to the protection, addressing, and other information needed
These files may be as large as 8⋅256⋅512, or l,048,576 (220) to access the file. It also permits a quite simple and rapid
bytes. algorithm for checking the consistency of a file system, for
The foregoing discussion applies to ordinary files. example verification that the portions of each device con-
When an I/O request is made to a file whose i-node indi- taining useful information and those free to be allocated are
cates that it is special, the last seven device address words disjoint and together exhaust the space on the device. This
are immaterial, and the list is interpreted as a pair of bytes algorithm is independent of the directory hierarchy, since it
which constitute an internal device name. These bytes spec- need only scan the linearly-organized i-list. At the same
ify respectively a device type and subdevice number. The time the notion of the i-list induces certain peculiarities not
device type indicates which system routine will deal with I/ found in other file system organizations. For example, there
O on that device; the subdevice number selects, for exam- is the question of who is to be charged for the space a file
ple, a disk drive attached to a particular controller or one of occupies, since all directory entries for a file have equal sta-
several similar typewriter interfaces. tus. Charging the owner of a file is unfair, in general, since
In this environment, the implementation of the mount one user may create a file, another may link to it, and the
system call (§3.4) is quite straightforward. Mount maintains first user may delete the file. The first user is still the owner
a system table whose argument is the i-number and device of the file, but it should be charged to the second user. The
name of the ordinary file specified during the mount, and simplest reasonably fair algorithm seems to be to spread the
whose corresponding value is the device name of the indi- charges equally among users who have links to a file. The
cated special file. This table is searched for each (i-number, current version of UNIX avoids the issue by not charging
device)-pair which turns up while a path name is being any fees at all.
scanned during an open or create; if a match is found, the i-
number is replaced by 1 (which is the i-number of the root

369 Electronic version recreated by Eric A. Brewer Communications July 1974

University of California at Berkeley of Volume 17
the ACM Number 7
4.1 Efficiency of the File System 5.2 Pipes
To provide an indication of the overall efficiency of Processes may communicate with related processes
UNIX and of the file system in particular, timings were made using the same system read and write calls that are used for
of the assembly of a 7621-line program. The assembly was file system I/O. The call
run alone on the machine; the total clock time was 35.9 sec,
filep = pipe( )
for a rate of 212 lines per sec. The time was divided as fol-
lows: 63.5 percent assembler execution time, 16.5 percent returns a file descriptor filep and creates an interprocess
system overhead, 20.0 percent disk wait time. We will not channel called a pipe. This channel, like other open flies, is
attempt any interpretation of these figures nor any compari- passed from parent to child process in the image by the fork
son with other systems, but merely note that we are gener- call. A read using a pipe file descriptor waits until another
ally satisfied with the overall performance of the system. process writes using the file descriptor for the same pipe. At
this point, data are passed between the images of the two
processes. Neither process need know that a pipe, rather
5. Processes and Images than an ordinary file, is involved.
Although interprocess communication via pipes is a
An image is a computer execution environment. It quite valuable tool (see §6.2), it is not a completely general
includes a core image, general register values, status of mechanism since the pipe must be set up by a common
open files, current directory, and the like. An image is the ancestor of the processes involved.
current state of a pseudo computer.
A process is the execution of an image. While the pro- 5.3 Execution of Programs
cessor is executing on behalf of a process, the image must Another major system primitive is invoked by
reside in core; during the execution of other processes it
execute(file, arg1, arg2, ..., argn)
remains in core unless the appearance of an active, higher-
priority process forces it to be swapped out to the fixed- which requests the system to read in and execute the pro-
head disk. gram named by file, passing it string arguments arg1, arg2,
The user-core part of an image is divided into three ..., argn. Ordinarily, arg1 should be the same string as file,
logical segments. The program text segment begins at loca- so that the program may determine the name by which it
tion 0 in the virtual address space. During execution, this was invoked. All the code and data in the process using exe-
segment is write-protected and a single copy of it is shared cute is replaced from the file, but open files, current direc-
among all processes executing the same program. At the tory, and interprocess relationships are unaltered. Only if
first 8K byte boundary above the program text segment in the call fails, for example because file could not be found or
the virtual address space begins a non-shared, writable data because its execute-permission bit was not set, does a return
segment, the size of which may be extended by a system take place from the execute primitive; it resembles a “jump”
call. Starting at the highest address in the virtual address machine instruction rather than a subroutine call.
space is a stack segment, which automatically grows down-
ward as the hardware’s stack pointer fluctuates. 5.4 Process Synchronization
Another process control system call
5.1 Processes
Except while UNIX is bootstrapping itself into opera- processid = wait( )
tion, a new process can come into existence only by use of causes its caller to suspend execution until one of its chil-
the fork system call: dren has completed execution. Then wait returns the pro-
processid = fork (label) cessid of the terminated process. An error return is taken if
the calling process has no descendants. Certain status from
When fork is executed by a process, it splits into two inde- the child process is also available. Wait may also present
pendently executing processes. The two processes have status from a grandchild or more distant ancestor; see §5.5.
independent copies of the original core image, and share
any open files. The new processes differ only in that one is 5.5 Termination
considered the parent process: in the parent, control returns Lastly,
directly from the fork, while in the child, control is passed
to location label. The processid returned by the fork call is exit (status)
the identification of the other process. terminates a process, destroys its image, closes its open
Because the return points in the parent and child pro- files, and generally obliterates it. When the parent is noti-
cess are not the same, each image existing after a fork may fied through the wait primitive, the indicated status is avail-
determine whether it is the parent or child process. able to the parent; if the parent has already terminated, the
status is available to the grandparent, and so on. Processes

370 Electronic version recreated by Eric A. Brewer Communications July 1974

University of California at Berkeley of Volume 17
the ACM Number 7
may also terminate as a result of various illegal actions or creates a file called there and places the listing there. Thus
user-generated signals (§7 below). the argument “〉there” means, “place output on there.” On
the other hand,
ed
6. The Shell
ordinarily enters the editor, which takes requests from the
For most users, communication with UNIX is carried on user via his typewriter. The command
with the aid of a program called the Shell. The Shell is a
ed 〈script
command line interpreter: it reads lines typed by the user
and interprets them as requests to execute other programs. interprets script as a file of editor commands; thus “〈script”
In simplest form, a command line consists of the command means, “take input from script.”
name followed by arguments to the command, all separated Although the file name following “〈” or “〉” appears to
by spaces: be an argument to the command, in fact it is interpreted
completely by the Shell and is not passed to the command
command arg1 arg2 ⋅ ⋅ ⋅ argn
at all. Thus no special coding to handle I/O redirection is
The Shell splits up the command name and the arguments needed within each command; the command need merely
into separate strings. Then a file with name command is use the standard file descriptors 0 and 1 where appropriate.
sought; command may be a path name including the “/”
character to specify any file in the system. If command is 6.2 Filters
found, it is brought into core and executed. The arguments An extension of the standard I/O notion is used to direct
collected by the Shell are accessible to the command. When output from one command to the input of another. A
the command is finished, the Shell resumes its own execu- sequence of commands separated by vertical bars causes
tion, and indicates its readiness to accept another command the Shell to execute all the commands simultaneously and
by typing a prompt character. to arrange that the standard output of each command be
If file command cannot be found, the Shell prefixes the delivered to the standard input of the next command in the
string /bin/ to command and attempts again to find the file. sequence. Thus in the command line
Directory /bin contains all the commands intended to be ls | pr –2 | opr
generally used.
ls lists the names of the files in the current directory; its out-
6.1 Standard I/O put is passed to pr, which paginates its input with dated
The discussion of I/O in §3 above seems to imply that headings. The argument “–2” means double column. Like-
every file used by a program must be opened or created by wise the output from pr is input to opr. This command
the program in order to get a file descriptor for the file. Pro- spools its input onto a file for off-line printing.
grams executed by the Shell, however, start off with two This process could have been carried out more clum-
open files which have file descriptors 0 and 1. As such a sily by
program begins execution, file 1 is open for writing, and is
ls 〉temp1
best understood as the standard output file. Except under
pr –2 〈temp1 〉temp2
circumstances indicated below, this file is the user’s type-
opr 〈temp2
writer. Thus programs which wish to write informative or
diagnostic information ordinarily use file descriptor 1. Con- followed by removal of the temporary files. In the absence
versely, file 0 starts off open for reading, and programs of the ability to redirect output and input, a still clumsier
which wish to read messages typed by the user usually read method would have been to require the ls command to
this file. accept user requests to paginate its output, to print in multi-
The Shell is able to change the standard assignments of column format, and to arrange that its output be delivered
these file descriptors from the user’s typewriter printer and off-line. Actually it would be surprising, and in fact unwise
keyboard. If one of the arguments ‘to a command is pre- for efficiency reasons, to expect authors of commands such
fixed by “〉”, file descriptor 1 will, for the duration of the as ls to provide such a wide variety of output options.
command, refer to the file named after the “〉”. For exam- A program such as pr which copies its standard input
ple, to its standard output (with processing) is called a filter.
Some filters which we have found useful perform character
ls
transliteration, sorting of the input, and encryption and
ordinarily lists, on the typewriter, the names of the files in decryption.
the current directory. The command
ls 〉there

371 Electronic version recreated by Eric A. Brewer Communications July 1974

University of California at Berkeley of Volume 17
the ACM Number 7
6.3 Command Separators: Multitasking also possible to execute commands conditionally on charac-
Another feature provided by the Shell is relatively ter string comparisons or on existence of given files and to
straightforward. Commands need not be on different lines; perform transfers of control within filed command
instead they may be separated by semicolons. sequences.
ls; ed
6.5 Implementation of the Shell
will first list the contents of the current directory, then enter The outline of the operation of the Shell can now be
the editor. understood. Most of tile time, the Shell is waiting for the
A related feature is more interesting. If a command is user to type a command. When the new-line character end-
followed by “&”, the Shell will not wait for the command ing the line is typed, the Shell’s read call returns. The Shell
to finish before prompting again; instead, it is ready imme- analyzes the command line, putting the arguments in a form
diately to accept a new command. For example, appropriate for execute. Then fork is called. The child pro-
cess, whose code of course is still that of the Shell, attempts
as source 〉output &
to perform an execute with the appropriate arguments. If
causes source to be assembled, with diagnostic output successful, this will bring in and start execution of the pro-
going to output; no matter how long the assembly takes, the gram whose name was given. Meanwhile, the other process
Shell returns immediately. When the Shell does not wait for resulting from the fork, which is the parent process, waits
the completion of a command, the identification of the pro- for the child process to die. When this happens, the Shell
cess running that command is printed. This identification knows the command is finished, so it types its prompt and
may be used to wait for the completion of the command or reads the typewriter to obtain another command.
to terminate it. The “&” may be used several times in a line: Given this framework, the implementation of back-
ground processes is trivial; whenever a command line con-
as source 〉output & ls 〉files &
tains “&”, the Shell merely refrains from waiting for the
does both the assembly and the listing in the background. In process which it created to execute the command.
the examples above using “&”, an output file other than the Happily, all of this mechanism meshes very nicely with
typewriter was provided; if this had not been done, the out- the notion of standard input and output files. When a pro-
puts of the various commands would have been intermin- cess is created by the fork primitive, it inherits not only the
gled. core image of its parent but also all the files currently open
The Shell also allows parentheses in the above opera- in its parent, including those with file descriptors 0 and 1.
tions. For example, The Shell, of course, uses these files to read command lines
and to write its prompts and diagnostics, and in the ordinary
(date; ls) 〉x &
case its children—the command programs—inherit them
prints the current date and time followed by a list of the cur- automatically. When an argument with “〈” or “〉” is given
rent directory onto the file x. The Shell also returns immedi- however, the offspring process, just before it performs exe-
ately for another request. cute, makes the standard I/O file descriptor 0 or 1 respec-
tively refer to the named file. This is easy because, by
6.4 The Shell as a Command: Command files agreement, the smallest unused file descriptor is assigned
The Shell is itself a command, and may be called recur- when a new file is opened (or created); it is only necessary
sively. Suppose file tryout contains the lines to close file 0 (or 1) and open the named file. Because the
as source process in which the command program runs simply termi-
mv a.out testprog nates when it is through, the association between a file
testprog specified after “〈” or “〉” and file descriptor 0 or 1 is ended
automatically when the process dies. Therefore the Shell
The mv command causes the file a.out to be renamed need not know the actual names of the files which are its
testprog. a.out is the (binary) output of the assembler, ready own standard input and output since it need never reopen
to be executed. Thus if the three lines above were typed on them.
the console, source would be assembled, the resulting pro- Filters are straightforward extensions of standard I/O
gram named testprog, and testprog executed. When the redirection with pipes used instead of files.
lines are in tryout, the command In ordinary circumstances, the main loop of the Shell
sh 〈tryout never terminates. (The main loop includes that branch of
the return from fork belonging to the parent process; that is,
would cause the Shell sh to execute the commands sequen- the branch which does a wait, then reads another command
tially. line.) The one thing which causes the Shell to terminate is
The Shell has further capabilities, including the ability discovering an end-of-file condition on its input file. Thus,
to substitute parameters and to construct argument lists
from a specified subset of the file names in a directory. It is
372 Electronic version recreated by Eric A. Brewer Communications July 1974
University of California at Berkeley of Volume 17
the ACM Number 7
when the Shell is executed as a command with a given input used instead of the Shell. Thus when editing system users
file, as in log in, they are inside the editor and can begin work imme-
diately; also, they can be prevented from invoking UNIX
sh 〈comfile
programs not intended for their use. In practice, it has
the commands in comfile will be executed until the end of proved desirable to allow a temporary escape from the edi-
comfile is reached; then the instance of the Shell invoked by tor to execute the formatting program and other utilities.
sh will terminate. Since this Shell process is the child of Several of the games (e.g. chess, blackjack, 3D tic-tac-
another instance of the Shell, the wait executed in the latter toe) available on UNIX illustrate a much more severely
will return, and another command may be processed. restricted environment. For each of these an entry exists in
the password file specifying that the appropriate game-
6.6 Initialization playing program is to be invoked instead of the Shell. Peo-
The instances of the Shell to which users type com- ple who log in as a player of one of the games find them-
mands are themselves children of another process. The last selves limited to the game and unable to investigate the
step in the initialization of UNIX is the creation of a single presumably more interesting offerings of UNIX as a whole.
process and the invocation (via execute) of a program called
init. The role of init is to create one process for each type-
writer channel which may be dialed up by a user. The vari-
7. Traps
ous subinstances of init open the appropriate typewriters for
input and output. Since when init was invoked there were The PDP-11 hardware detects a number of program
no files open, in each process the typewriter keyboard will faults, such as references to nonexistent memory, unimple-
receive file descriptor 0 and the printer file descriptor 1. mented instructions, and odd addresses used where an even
Each process types out a message requesting that the user address is required. Such faults cause the processor to trap
log in and waits, reading the typewriter, for a reply. At the to a system routine. When an illegal action is caught, unless
outset, no one is logged in, so each process simply hangs. other arrangements have been made, the system terminates
Finally someone types his name or other identification. The the process and writes the user’s image on file core in the
appropriate instance of init wakes up, receives the log-in current directory. A debugger can be used to determine the
line, and reads a password file. If the user name is found, state of the program at the time of the fault.
and if he is able to supply the correct password, init changes Programs which are looping, which produce unwanted
to the user’s default current directory, sets the process’s user output, or about which the user has second thoughts may be
ID to that of the person logging in, and performs an execute halted by the use of the interrupt signal, which is generated
of the Shell. At this point the Shell is ready to receive com- by typing the “delete” character. Unless special action has
mands and the logging-in protocol is complete. been taken, this signal simply causes the program to cease
Meanwhile, the mainstream path of init (the parent of execution without producing a core image file.
all the subinstances of itself which will later become Shells) There is also a quit signal which is used to force a core
does a wait. If one of the child processes terminates, either image to be produced. Thus programs which loop unex-
because a Shell found an end of file or because a user typed pectedly may be halted and the core image examined with-
an incorrect name or password, this path of init simply rec- out prearrangement.
reates the defunct process, which in turn reopens the appro- The hardware-generated faults and the interrupt and
priate input and output files and types another login quit signals can, by request, be either ignored or caught by
message. Thus a user may log out simply by typing the end- the process. For example, the Shell ignores quits to prevent
of-file sequence in place of a command to the Shell. a quit from logging the user out. The editor catches inter-
rupts and returns to its command level. This is useful for
6.7 Other Programs as Shell stopping long printouts without losing work in progress (the
The Shell as described above is designed to allow users editor manipulates a copy of the file it is editing). In sys-
full access to the facilities of the system since it will invoke tems without floating point hardware, unimplemented
the execution of any program with appropriate protection instructions are caught, and floating point instructions are
mode. Sometimes, however, a different interface to the sys- interpreted.
tem is desirable, and this feature is easily arranged.
Recall that after a user has successfully logged in by
supplying his name and password, init ordinarily invokes
8. Perspective
the Shell to interpret command lines. The user’s entry in tile
password file may contain the name of a program to be Perhaps paradoxically, the success of UNIX is largely
invoked after login instead of the Shell. This program is due to the fact that it was not designed to meet any pre-
free to interpret the user’s messages in any way it wishes. defined objectives. The first version was written when one
For example, the password file entries for users of a of us (Thompson), dissatisfied with the available computer
secretarial editing system specify that the editor ed is to be
373 Electronic version recreated by Eric A. Brewer Communications July 1974
University of California at Berkeley of Volume 17
the ACM Number 7
facilities, discovered a little-used system PDP-7 and set out Another important aspect of programming conve-
to create a more hospitable environment. This essentially nience is that there are no “control blocks” with a compli-
personal effort was sufficiently successful to gain the inter- cated structure partially maintained by and depended on by
est of the remaining author and others, and later to justify the file system or other system calls. Generally speaking,
the acquisition of the PDP-11/20, specifically to support a the contents of a program’s address space are the property
text editing and formatting system. Then in turn the 11/20 of the program, and we have tried to avoid placing restric-
was outgrown, UNIX had proved useful enough to persuade tions on the data structures within that address space.
management to invest in the PDP-11/45. Our goals through- Given the requirement that all programs should be
out the effort, when articulated at all, have always con- usable with any file or device as input or output, it is also
cerned themselves with building a comfortable relationship desirable from a space-efficiency standpoint to push
with the machine and with exploring ideas and inventions device-dependent considerations into the operating system
in operating systems. We have not been faced with the need itself. The only alternatives seem to be to load routines for
to satisfy someone else’s requirements, and for this freedom dealing with each device with all programs, which is expen-
we are grateful. sive in space, or to depend on some means of dynamically
Three considerations which influenced the design of linking to the routine appropriate to each device when it is
UNIX are visible in retrospect. actually needed, which is expensive either in overhead or in
First, since we are programmers, we naturally designed hardware.
the system to make it easy to write, test, and run programs. Likewise, the process control scheme and command
The most important expression of our desire for program- interface have proved both convenient and efficient. Since
ming convenience was that the system was arranged for the Shell operates as an ordinary, swappable user program,
interactive use, even though the original version only sup- it consumes no wired-down space in the system proper, and
ported one user. We believe that a properly designed inter- it may be made as powerful as desired at little cost, In par-
active system is much more productive and satisfying to use ticular, given the framework in which the Shell executes as
than a “batch” system. Moreover such a system is rather a process which spawns other processes to perform com-
easily adaptable to noninteractive use, while the converse is mands, the notions of I/O redirection, background pro-
not true. cesses, command files, and user-selectable system
Second there have always been fairly severe size con- interfaces all become essentially trivial to implement.
straints on the system and its software. Given the partiality
antagonistic desires for reasonable efficiency and expres- 8.1 Influences
sive power, the size constraint has encouraged not only The success of UNIX lies not so much in new inventions
economy but a certain elegance of design. This may be a but rather in the full exploitation of a carefully selected set
thinly disguised version of the “salvation through suffer- of fertile ideas, and especially in showing that they can be
ing” philosophy, but in our case it worked. keys to the implementation of a small yet powerful operat-
Third, nearly from the start, the system was able to, and ing system.
did, maintain itself. This fact is more important than it The fork operation, essentially as we implemented it,
might seem. If designers of a system are forced to use that was present in the Berkeley time-sharing system [8]. On a
system, they quickly become aware of its functional and number of points we were influenced by Multics, which
superficial deficiencies and are strongly motivated to cor- suggested the particular form of the I/O system calls [9] and
rect them before it is too late. Since all source programs both the name of the Shell and its general functions, The
were always available and easily modified on-line, we were notion that the Shell should create a process for each com-
willing to revise and rewrite the system and its software mand was also suggested to us by the early design of Mul-
when new ideas were invented, discovered, or suggested by tics, although in that system it was later dropped for
others. efficiency reasons. A similar scheme is used by TENEX [10].
The aspects of UNIX discussed in this paper exhibit
clearly at least the first two of these design considerations.
The interface to the file system, for example, is extremely 9. Statistics
convenient from a programming standpoint. The lowest
possible interface level is designed to eliminate distinctions The following statistics from UNIX are presented to
between the various devices and files and between direct show the scale of the system and to show how a system of
and sequential access. No large ‘‘access method” routines this scale is used. Those of our users not involved in docu-
are required to insulate the programmer from the system ment preparation tend to use the system for program devel-
calls; in fact, all user programs either call the system opment, especially language work. There are few important
directly or use a small library program, only tens of instruc- “applications” programs.
tions long, which buffers a number of characters and reads
or writes them all at once.

374 Electronic version recreated by Eric A. Brewer Communications July 1974

University of California at Berkeley of Volume 17
the ACM Number 7
9.1 Overall of them are caused by hardware-related difficulties such as
power dips and inexplicable processor interrupts to random
72 user population locations. The remainder are software failures. The longest
14 maximum simultaneous users
uninterrupted up time was about two weeks. Service calls
300 directories
4400 files average one every three weeks, but are heavily clustered.
34000 512-byte secondary storage blocks used Total up time has been about 98 percent of our 24-hour,
365-day schedule.
9.2 Per day (24-hour day, 7-day week basis)
There is a “background” process that runs at the lowest Acknowledgments. We are grateful to R.H. Canaday,
possible priority; it is used to soak up any idle CPU time. It L.L. Cherry, and L.E. McMahon for their contributions to
has been used to produce a million-digit approximation to UNIX. We are particularly appreciative of the inventiveness,
the constant e – 2, and is now generating composite thoughtful criticism, and constant support of R. Morris,
pseudoprimes (base 2). M.D. McIlroy, and J.F. Ossanna.
1800 commands
4.3 CPU hours (aside from background) References
70 connect hours 1. Digital Equipment Corporation. PDP-11/40 Processor
30 different users Handbook, 1972, and PDP-11/45 Processor Handbook. 1971.
75 logins 2. Deutsch, L.P., and Lampson, B.W. An online editor. Comm.
ACM 10, 12 (Dec, 1967) 793–799, 803.
9.3 Command CPU Usage (cut off at 1%) 3. Richards, M. BCPL: A tool for compiler writing and system
programming. Proc. AFIPS 1969 SJCC, Vol. 34, AFIPS Press,
15.7% C compiler 1.7% Fortran compiler Montvale, N.J., pp. 557–566.
15.2% users’ programs 1.6% remove file 4. McClure, R.M. TMG—A syntax directed compiler. Proc.
11.7% editor 1.6% tape archive
ACM 20th Nat. Conf., ACM, 1965, New York, pp. 262–274.
5.8% Shell (used as a com- 1.6% file system consistency
mand, including com- check 5. Hall. A.D. The M6 macroprocessor. Computing Science
mand times) 1.4% library maintainer Tech. Rep. #2, Bell Telephone Laboratories, 1969.
5.3% chess 1.3% concatenate/print files 6. Ritchie, D.M. C reference manual. Unpublished
3.3% list directory 1.3% paginate and print file memorandum, Bell Telephone Laboratories, 1973.
3.1% document formatter 1.1% print disk usage 7. Aleph-null. Computer Recreations. Software Practice and
1.6% backup dumper 1.0% copy file Experience 1, 2 (Apr.–June 1971), 201–204.
1.8% assembler 8. Deutsch, L.P., and Lampson, B.W. SDS 930 time-sharing
system preliminary reference manual. Doc. 30.10.10, Project
9.4 Command Accesses (cut off at 1%) GENIE, U of California at Berkeley, Apr. 1965.
9. Feiertag. R.J., and Organick, E.I. The Multics input-output
15.3% editor 1.6% debugger system. Proc. Third Symp. on Oper. Syst. Princ., Oct. 18–20,
9.6% list directory 1.6% Shell (used as a command) 1971, ACM, New York, pp. 35–41.
6.3% remove file 1.5% print disk availability
10. Bobrow, D.C., Burchfiel, J.D., Murphy, D.L., and
6.3% C compiler 1.4% list processes executing
6.0% concatenate/print file 1.4% assembler Tomlinson, R.S. TENEX, a paged time sharing system for the
6.0% users’ programs 1.4% print arguments PDP-10. Comm. ACM 15, 3 (Mar. 1972) 135–143.
3.3% list people logged on 1.2% copy file
system 1.1% paginate and print file
3.2% rename/move file 1.1% print current date/time
3.1% file status 1.1% file system consistency
1.8% library maintainer check
1.8% document formatter 1.0% tape archive
1.6% execute another com-
mand conditionally

9.5 Reliability
Our statistics on reliability are much more subjective
than the others. The following results are true to the best of
our combined recollections. The time span is over one year
with a very early vintage 11/45.
There has been one loss of a file system (one disk out
of five) caused by software inability to cope with a hard
ware problem causing repeated power fail traps. Files on
that disk were backed up three days.
A “crash” is an unscheduled system reboot or halt.
There is about one crash every other day; about two-thirds

375 Electronic version recreated by Eric A. Brewer Communications July 1974

University of California at Berkeley of Volume 17
the ACM Number 7