From a Research Environment to Text Work
After Bell Labs withdrew from the Multics project in 1969, Ken Thompson, Dennis Ritchie and others wanted to retain an environment convenient for interactive programming. At Murray Hill, New Jersey, they used a Digital Equipment Corporation PDP-7 to gradually build a file system, command interpreter and small tools. When they moved to a newly acquired PDP-11 in 1970, text editing and typesetting became concrete applications for securing support, with Joseph Ossanna playing an important role.
The UNIX Programmer's Manual dated November 3, 1971 and attributed to Thompson and Ritchie therefore marked a stage in documenting the system. Development had begun in 1969, so the document's date cannot serve as a single birthday when Unix appeared from nothing. The machine it described already performed real work but did not yet have all the features of later Unix.
Writing Down the System as It Ran
The manual had seven parts covering commands, system calls, subroutines, special files, file formats, user-maintenance programs and miscellaneous material. Each entry described its purpose, invocation, behavior, associated files, diagnostics, known bugs and maintainer. Readers could learn both how to enter a command and whom to contact when problems arose.
The editors explicitly chose to describe actual behavior at the time each entry was written. Entries carried their own dates and appeared on independent pages convenient for replacement and updating, rather than presenting changing software as an immutable specification. The manual itself was made using the ed editor and roff formatter, making the documentation a real product of the system's tools: tools produced documentation, and documentation enabled others to use the tools.
References: [1]
Files Connected Editing and Computing
Filenames and directories let users preserve text, programs and results without arranging disk locations anew for every task. The first edition's ed edited by lines: it read a file into an editing buffer, and changes had to be saved with a write command. Pattern-based searching and substitution allowed repeated processing of similarly structured text rather than character-by-character retyping.
Devices also entered the system interface through special files, and programs could read and write open files. The sh command interpreter could redirect output into a file and let another command read from it. Such combinations required explicit intermediate files and sequential steps; the first edition did not yet have the familiar later pipe operator. This distinction shows how tool composition gradually grew out of small-scale practice.
How a Shared Computer Executed Commands
When a user entered a command, the shell located and launched the corresponding program. fork created a child process, exec replaced the executable content of a process with a specified program, wait let the parent await a child's termination, and exit ended execution. Separating these responsibilities allowed the shell either to wait for a command or to run a task in the background at the user's request. The command interpreter was itself a user program, so methods of operation did not all have to be fixed in the kernel.
Sharing did not mean that every program remained in memory continuously. The early PDP-11 had only 24 kilobytes of core memory, relied on disk swapping to accommodate processes and lacked hardware memory protection. File permissions, login identities and process management provided order for collaboration, but were not equivalent to the isolation of later mature systems; an uncontrolled program could still affect the entire machine.
Proving It in Work Before Reaching a Wider Audience
In 1971, text-processing work in Bell Labs' patent department gave Unix users beyond programmers. Typists needed to edit, format and print application documents, while practical requirements such as line numbering in patent files prompted improvements to the tools. The computer thus had to do more than demonstrate algorithms: it needed to preserve files over time, accept repeated revisions and deliver readable documents.
A conference presentation in 1973 and a paper in Communications of the ACM in 1974 subsequently introduced Unix to a broader computing-research community. They described a system still developing, so all their features cannot be projected onto the 1971 manual. The first edition's significance lies in preserving a verifiable starting point: files supplied persistent objects, processes units of execution, and commands entry points for operation, while concise, updateable explanations turned developers' experience into shared knowledge that could be taught.