C, Pipes, and the Portability of Unix

Unix became influential not because one machine or one program was uniquely important, but because a compact set of interfaces made systems software easier to move, inspect, and combine. C and pipes were central to that result. They grew from specific work at Bell Labs in the early 1970s, under the constraints of small minicomputers and a research organization that could share source with universities. Neither made software automatically portable or programs automatically simple; both made useful trade-offs visible.

From BCPL to B to C

BCPL, designed by Martin Richards in the 1960s, was a typeless systems language intended to be adaptable to different machines. Ken Thompson made a simplified descendant, B, while working on early Unix on the PDP-7 and then the PDP-11. B was useful for early tools, but its word-oriented model was a poor fit for the PDP-11's byte addressing and growing need for efficient systems code.

From 1969 through 1971, B and Ritchie's intermediate “New B” (NB) supplied the immediate antecedent work. Ritchie developed C at Bell Labs from that work in 1972–1973. C added types and expressions that mapped well to the PDP-11 while retaining a comparatively small language and a compiler that could itself be ported. Calling C merely “portable assembly” is misleading: it has an abstract language and compilers make choices. But it deliberately exposes addresses, layout, and low-level operations more directly than many application languages, which made it practical for kernels, compilers, and utilities.

Stage	Documented contribution	Consequence for Unix work
BCPL	Richards's compact, implementation-minded language.	Provided an important ancestor of B's style.
B	Thompson's stripped-down language for early Unix-era systems.	Helped move work out of assembly, but lacked C's typed byte-oriented model.
C	Ritchie's language and compiler work on the PDP-11.	Made a large body of operating-system source feasible to retarget.
Unix in C	Most of the kernel was rewritten for the Fourth Edition era; the 1973 paper reported the approach.	Unix could be carried to new machines without translating every line of assembly.

Rewriting Unix changed the unit of distribution

The first Unix ran largely in PDP-7 and PDP-11 assembly language. A C rewrite did not eliminate machine-specific code: boot code, interrupt handling, context switching, device drivers, and assumptions about byte order or word size still require close hardware knowledge. It did, however, separate much more of the kernel and its utilities from a particular instruction set. A port could preserve the system-call model and user programs while replacing a relatively small machine-dependent layer.

Thompson and Ritchie's 1974 Communications of the ACM paper described Unix as a time-sharing system written in C. That was a technical argument and a demonstration, not a claim that C alone guaranteed compatibility. Later ports exposed undefined behavior, integer-size assumptions, data-layout dependencies, and compiler differences. Those limitations remain familiar to C programmers maintaining code across 32- and 64-bit processors today.

Licensing and a university culture

AT&T was constrained by a 1956 consent decree from entering the general computer business. Bell Labs could license Unix, including source, to universities and research users at low cost rather than market it as an ordinary product. The arrangement was not open source in the modern sense: the code was copyrighted, licensed, and subject to redistribution restrictions. Yet source availability let students and researchers read, modify, and exchange ideas around a working operating system.

John Lions's 1976 commentary on Version 6 kernel source became especially important in teaching. Its circulation is often described as wholly unofficial; the more precise account is that it was distributed under the applicable Unix license and was later restricted when AT&T tightened terms. Lions explained a real, small kernel line by line, helping establish source study as a systems-education practice. A famous book did not create the culture by itself; access, departmental computing needs, and many contributors did.

Pipes turn processes into a composition mechanism

Doug McIlroy, who led Bell Labs' Computing Techniques Research Department, long advocated a “software components” approach: make programs reusable and connect them. He is associated with proposing the Unix pipe; Thompson developed and implemented the mechanism around 1972, and pipes first appear in the Third Edition Unix documentation in 1973. The kernel feature connects one process's output file descriptor to another's input, while the shell supplies the convenient | notation, starts the pipeline commands, and waits for a foreground pipeline to finish. Interactive shells may also place pipeline commands in a process group for job control; that is a shell/job-control facility rather than a requirement of the pipe itself.

$ cut -d: -f1 /etc/passwd | sort | uniq | wc -l
     42

$ producer | consumer 2>errors.log

In the first pipeline, each program has a narrow responsibility: select a field, order lines, remove adjacent duplicates, then count. The shell creates processes and arranges standard input and output; the programs need not be linked into one application. The second reminder matters operationally: standard error is normally separate from the pipe, so diagnostics can be recorded without being mistaken for input data.

Composition has boundaries

A traditional pipe is a byte stream, not a record protocol. A reader can receive any sized chunk; writers and readers must define framing when it matters.
Text makes ad-hoc inspection convenient, but filenames can contain spaces, newlines, and bytes that a terminal should not display. Robust scripts choose interfaces designed for such names, such as find -print0 with a matching consumer where available.
Shell pipelines have status and error-handling subtleties. POSIX shell does not require every extension offered by modern shells, so production scripts should state their shell and test their failure behavior.
For large or structured workloads, a database, a typed API, or one purpose-built program may be clearer and safer than a long textual pipeline.

The pattern still appears in CI jobs, log processing, containers, and data tools: processes communicate through file descriptors, sockets, or other streams. Modern systems add JSON, RPC, message queues, and graphical interfaces, but the small-interface discipline remains useful when it makes failure modes and ownership clear.

A short chronology

Date	Event	What endured
1966	BCPL is designed by Martin Richards.	A compact systems-language lineage feeds into B and C.
1969–1971	Thompson develops B; Ritchie’s NB work extends that antecedent at Bell Labs.	Unix development begins to move beyond assembly and prepares the ground for C.
1972–1973	Ritchie develops C from the B/NB lineage.	A typed, byte-oriented systems language becomes the basis for the Unix rewrite.
1972–1973	Pipes are proposed and developed circa 1972; their first documented Unix appearance is in the Third Edition manual (1973).	File descriptors and stream composition become core Unix idioms.
1973	Unix is substantially rewritten in C and presented publicly.	Source portability becomes a practical strategy.
1975–1976	Version 6 source reaches licensed universities; Lions prepares his commentary.	Unix becomes a major object of systems teaching and experimentation.
1988 onward	POSIX specifies common C and shell interfaces.	Portable source targets an agreed interface, not one vendor's behavior.

C and Unix interfaces now

C is still used for kernels, embedded systems, databases, runtimes, compilers, and performance-sensitive libraries. POSIX defines C interfaces such as fork(), exec(), pipe(), open(), and read(); Unix-like systems retain them with platform-specific extensions. Linux is Unix-like rather than identical to a historical Research Unix release, and Windows, macOS, and the BSDs expose different subsets or compatibility layers. A program that says “C” or “Unix” without naming its compiler, standard, and target API leaves important facts unstated.

Today's toolchains also make the historical trade-off more explicit. Compilers optimize aggressively under C's rules, sanitizers can detect many memory errors during testing, and static analyzers help find unchecked paths. None replaces careful ownership, bounds checking, and portable interfaces. The durable legacy is not that old C code should be preserved unchanged, but that an operating system can offer small, documented interfaces on which independent tools and implementations can meet.