The following is an account of an interview with Doug McIlroy, head of department where UNIX started.
 
       In 1969, Bell Labs decided to get out of the Multics project.  It became clear that Research was a drag on the Computing Center's budget.  "They had a million dollars worth of equipment in the attic that was sitting there being played with by three people. ...A clean, sharp decision was made to get out.  The project did not wind down.  It just stopped."

       With the experience gained from Multics, "Ken Thompson began to build his own operating system for the giant 645, starting from scratch."   In the wee hours of the night, Thompson would take the system down when nobody was using it.

       At the same time, the development group was still working.  The Computer Center still owned the machines and was separate from Research.  So Computing Research had no computers.  "Visual and acoustics research had had computers for some time."  They were interested in listening to signals in real time and make digital filters, but this ate up all the cycles of the machine.  As more and more minicomputers came available, Visual and Acoustics Research kept getting them.  They had nice hardware, and we would comment on how inefficiently they were using their cycles.  Because they really didn't like making software, when things got tough, they would just buy another machine.  And if the machines got a little faster, they would just throw out the old one.  That was the origin of the PDP7."

       The PDP7 had an improved graphics engine, that had been sitting idle.  "That's what Thompson grabbed and finally used to build early versions of Unix on."  As Thompson brought along his operating system, Ritchie joined in.  McIlroy also saw its potential, and, being head of the department, he muscled in.

       One place that McIlroy exerted managerial control of Unix was in pushing for pipes.  The idea of pipes goes way back.  McIlroy began doing macros in the CACM back in 1959 or 1960.  Macros involve switching among many data streams.  "You're taking in your input, you suddenly come to a macro call, and that says, stop taking input from here, go take it from the definition.  In the middle of the definition, you'll find another macro call.  Somewhere I talked of a macro processor as a switchyard for data streams.  ...In 1964, [according to a] paper hanging on Brian's wall, I talked about screwing together streams like garden hoses."

       "On MULTICS, Joe Osanna, ... was actually beginning to build a way to do input-output plumbing.  Input-output was interpreted over this idea of the segmented address space in the file system: files were really just segments of the same old address space.  Nevertheless, you had to do I/O because all the programming languages did it.   And he was making ways of connecting programs together."

       While Thompson and Ritchie were laying out their file system, McIlroy was "sketching out how to do data processing by connecting together cascades of processes and looking for a kind of prefix-notation language for connecting processes together."

       Over a period from 1970 to 1972, McIlroy suggested proposal after proposal.  He recalls the break-through day:  "Then one day, I came up with a syntax for the shell that went along with the piping, and Ken said, I'm gonna do it.  He was tired of hearing all this stuff."  Thompson didn't do exactly what McIlroy had proposed for the pipe system call, but "invented a slightly better one.  That finally got changed once more to what we have today.  He put pipes into Unix."  Thompson also had to change most of the programs, because up until that time, they couldn't take standard input.  There wasn't really a need; they all had file arguments. "GREP had a file argument, CAT had a file argument."

       The next morning, "we had this orgy of  `one liners.'  Everybody had a one liner.  Look at this, look at that.  ...Everybody started putting forth the UNIX philosophy.  Write programs that do one thing and do it well.  Write programs to work together.  Write programs that handle text streams, because that is a universal interface."   Those ideas which add up to the tool approach, were there in some unformed way before pipes, but they really came together afterwards.  Pipes became the catalyst for this UNIX philosophy.  "The tool thing has turned out to be actually successful.  With pipes, many programs could work together, and they could work together at a distance."

       APL influenced the development of pipes.  APL did not allow the use of operators with variants, which many utilities had at the time.  It only took a willingness to throw in a new separator, the vertical bar.  About four years passed, from the time they started talking about developing a new separator, to the time it happened.

       To most of the Research group at Bell Labs, the computing theory was there on the side, while they had functionality to deal with.  Most of the group members were more computer types than mathematicians, even though they wrote papers occasionally with mathematical notation.  McIlroy went to Oxford for a year, solely to "imbibe the notion of semantics form the source."  The Research group included system builders like Thompson, and theoretical scientists like Aho.  "Aho handed out paper after paper of slightly different models of parsing and automata, and that was supported with the overt idea that one day [it] would feed computing practice."

    "There is a case where there's absolutely no doubt that, overtly, theory fed into what we did.  When the sound theory of parsing went into a compiler-writing system, it became available to the masses.  There are lots of other places where theory is an inspiration, or it's in the back of your mind."  Thompson wrote one famous recognizer, which is still used in GREP.   And Aho decided that he was going to take that part of automata theory, and so he built EGREP.  "So, you have the deterministic [parser] in EGREP, and the nondeterministic one in GREP."

    "I think really that YACC and GREP are what people hold up as the `real tools' and they are the ones where we find a strong theoretical underpinning.  TROFF has none.   [While] it's used, and indispensable, nobody holds it up as a programming gem."

    This concludes what is contained in the interview, as it relates to Unix.