TL;DR: In UNIX version 1, the easiest way to get unfiltered, human-typed input onto the standard output was with an argument-less
cat. A few versions later,
echo would provide another simple means to get human-typed input onto the standard output.
It is such a bad default that I assume it must have been intended for some other context where this behavior would make more sense.
cat was introduced in 1971, UNIX version 1, for the PDP series of minicomputers. Computer I/O at that time used fancy typewriters called teletypes for both input and output(*):
Popular minicomputers of the late 1960s and early ’70s, such as the PDP-8, PDP-11, and the Data General Nova, supported ASCII encoding, making the Model 33 [teletype] an ideal low-cost (relatively speaking) input/output (I/O) terminal for them. In particular, the PDP series by DEC were influential machines, and if you look up historical photos of them, you’ll almost always see a Teletype Model 33 in use beside them.
When you used a teletype with a mainframe [sic] computer like these, you’d see your own local input on paper as you typed, and then you’d receive a response from the computer printed below it as the teletype printed to a continuous feed of rolled paper stored within the unit.
In 1970, Dennis Ritchie and Ken Thompson developed the UNIX operating system on a PDP-11 using Model 33 teletypes as interfaces, and some of the teletype-related design choices that they made are still with us today.
Where the "bad default" of today made more sense back then was as a way to pass human-typed text to the output teletype, without having to go through a named file -- remember this was before McIlroy had conceptualized pipes and the only way to get data into a named file was to write a program (on tape or hand-entered line by line) that created a named file in the filesystem (there was no
echo command until version 6, written by McIlroy no less):
--- Here is Today's Weather Report ---
In this example, the user invokes
cat and types a line of text that acts as a header indicating that the day's weather report is coming, ending that input with an end-of-file sequence. Then the user invokes
cat again to output a file called
Of course, the commands the user types will appear on their own console (de facto because a teletype is just an ink-on-paper typewriter), but importantly the output of these
cat commands will go to standard out, which may be a different teletype than the one on which the commands are entered.
For example, in this picture the console teletype giving the commands (middle of photo) is routing output to the large line printer (left of photo):
In this picture, we see the Self Service I/O Area at Columbia University, circa early 1980. Notice that this multi-user environment was also multi-room, with input terminals a good distance away from output terminals.
The uniformity of treating all devices as files combined with the elegance of all programs having standard input and output channels, allowed UNIX to adapt to many environments and configurations without having to reprogram for every scenario. As reprogramming was expensive and specialized, only the most versatile programs endured:
cat, now more than 50 years old and unchanged in its essential operation, is proof.
In search of direct, authoritative historical evidence, I turned to my copy of "UNIX: A History and Memoir" by Brian Kernighan. I can find no explicit statement that the interactive console for standard input was an explicit design choice, but there are a few choice paragraphs on this subject.
It’s interesting to speculate about how differently things might have turned out if Unix had been developed in a world with punch cards instead of Teletypes.
-- Kernighan, Brian. UNIX: A History and a Memoir (p. 182). Kindle Edition.
Ken is typing at a Model 33 Teletype, a sturdy but slow and noisy device, basically a computer-controlled electro-mechanical typewriter that could only print in upper case, at 10 characters per second. The Model 33 dates from 1963 but earlier versions had been in widespread use since the early 1930s.
Teletype Corporation was a part of AT&T, and Teletypes were widely used throughout the Bell System and elsewhere for sending messages, and later for connecting to computers. Whatever was typed on the Teletype keyboard was sent to the computer, and responses were printed (in upper case) on a long roll of paper; the tops of the paper rolls are just visible in the picture. Arguably, one reason why many command names on Unix are short is that it took considerable physical force to type on a Model 33, and printing was slow.
Someone even built an experimental “portable” Model 33. The keyboard and printer were shoehorned into a suitcase-like container that in theory could be carried around, though at 55 pounds (25 kg) you wouldn’t carry it far. (It had no wheels either.) It was connected to a remote computer through a dial-up phone connection and a built-in acoustic coupler: plug a telephone handset into a couple of rubber sockets and the coupler converted data into sound and back again, rather like a fax machine.
-- Kernighan, Brian. UNIX: A History and a Memoir (p. 57-58). Kindle Edition.
It's interesting that in 1978, 6 years after
cat was written, McIlroy summarized "[T]he Unix philosophy, a style of programming, of how to approach a computing task" with this point:
Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
-- Kernighan, Brian. UNIX: A History and a Memoir (p. 183). Kindle Edition.
Perhaps had pipes and shell redirection been a part of UNIX version 1, then a dedicated program like
read would have been the only way to read bytes from the interactive console and the absence of a standard input stream to a program would have immediately exited.
The PDP-1 Input-Output Systems Manual is a great reference for how the PDP series worked at a line level -- signals, bits, and wires -- and provides a
(*) Ben Gurley (designer of the PDP-1) had written a subroutine for displaying characters on the PDP-1 scope (barely a character display), but (a) that wasn't universally installed and (b) it still treated the display as a teletype.