Download Unix – Small Beginnings

Introduction to Unix
Unix – Small Beginnings Pg 1
Unix – Small Beginnings
Ray Lockwood
Points:
 AT&T continues its operating system research.
 Started with a file system.
 The name “Unix”.
 Creation of the C language.
 Redirection and piping.
AT&T Still Needed an Operating System
The Old Team
Bell Labs still needed an interactive operating system. After AT&T left Multics, a handful
of the Bell Labs Multics programmers restarted work on a new operating system:1
• Ken Thompson
• Dennis Ritchie
• Doug McIlroy
• Joe Ossanna
• Rudd Canaday
• Brian Kernighan
Multics was not a complete loss; it did, in fact, work to an extent. Dennis Ritchie:2
Ken Thompson
Ken Thompson
had a practical
electronics engeneering background.
“Even though Multics could not then support many users, it could
support us, albeit at exorbitant cost”.
The ideas behind Multics formed the starting point for a more modest approach to
building an operating system.
Interactive Computing Leads To Sharing
After they had worked with Multics for a few years, the Bell Labs programmers
discovered something surprising: It wasn't that Multics allowed people to share the
machine, it was that it allowed them to work together.
Doug McIlroy:
“It was that it allowed many people to work in the same huge pot of
data and it was this synergy of sharing data, to be able to quickly
look at other people's files, pass messages around and so on, that
was the best thing that time sharing had to offer. The other was
merely an economic advantage, but the one of sharing was a
qualitatively different way of using the machines”.
1
2
Ken Thompson photo: http://www.computerhistory.org/chess/full_record.php?iid=stl-431e1a07c0d41
Dennis Ritchie photo: http://www.ieeeghn.org/wiki/index.php/Dennis_Ritchie
COP3353
Dennis Ritchie
Dennis Ritchie
had a physics
and math background.
Introduction to Unix
Unix – Small Beginnings Pg 2
Dennis Ritchie:
“We didn't want to lose the pleasant niche we occupied...What we
wanted to preserve was just not a good environment in which to do
programming, but a system around which a fellowship could form”.
In Multics, they had discovered a communications tool – they wanted to preserve that.
A Few Good Multics Concepts
The impression that Multics made on the Bell Labs programmers was not all bad. Dennis
Ritchie noted the good points:
“There were a lot of cultural things that were sort of taken over
wholesale:
•
•
•
•
The hierarchical file system.
The characters you use to edit lines as you're typing.
The notion of a command line.
An explicit shell program. In fact the name 'shell' came from Multics”.
Ken Thompson:
"The things that I liked enough to actually take were the hierarchical
file system and the shell – a separate process that you can replace
with some other process".
Shell
The environment
you type
commands into.
The program
that gives you a
command-line
user interface.
A user interface:
You talk to it,
and it talks to
the operating
system.
While he was sitting around Bell Labs waiting to be let go for lack of work, Thompson
decided to spend his time working on these good ideas, starting with the file system.
Thompson's partner in his informal endeavor was Dennis Ritchie, who remembers:
“I think that (the file system research) was basically part of Ken's
desire to do a system of his own…The structure of this proposed
system which was in most ways the predecessor of Unix…Most of
the ideas were Ken's”.
From a File System To an Operating System
The first task was to build a file system for some future OS. The top priority
was sharing and “fellowship” – every user must have access to each other's
files. An idea was roughed and Thompson wrote it in a day for a PDP-73 minicomputer. It was cross-assembeled on a GE635 and transferred by paper tape.
PDP-7
3
PDP-7 photo: http://www.faqs.org/docs/artu/ch02s01.html
COP3353
Introduction to Unix
Unix – Small Beginnings Pg 3
However, there was no software to test this new file system. To provide it, Thompson
took a month in the summer of 1969 and spent a week each on:
-
an operating system kernel (to provide the notion of “processes”)
a shell
an editor
an assembler
When Thompson was done at the end of the month, the file system had grown into an
Operating System. It was “self supporting” – it no longer needed the GE635's crossassembler. In one month an Operating System was born!
The Name “Unix”
Someone called the new operating system “Unics” as a parody of Multics, the “U”
meaning “Uniplexed” instead of “Multiplexed” – “Just one of whatever Multics had lots
of”. It also meant “Eunuchs” – “Multics with parts missing”.
The next year, Brian Kernighan4 decided the spelling “Unix” had more flair.
“B” – a High-Level Language
Like in the Multics project, Ken Thompson wanted his operating system to be written in a
high level language so it would be easy to build, easy for others to understand, and easy
to port to other platforms.
FORTRAN was the technical language of the day, so that was the target for Thompson to
transliterate the Unix assembler code to. Two days later, he decided that FORTRAN just
wouldn't do.
In Multics, the Bell Labs engineers wrote utilities in a language from at the University of
Cambridge (UK) called BCPL. They liked the language, but it was too complex for the
little PDP-7, so Thompson pared it down to fit. He named it “B” for “Stripped Down
BCPL”.
He also paired down the syntax to minimize the keystrokes on the clumsy Teletypes used
for typing. It looked a little like C.
B had only one data type, a PDP-7 word, it was interpreted (quite slow), and it didn't
support the functionality needed for an operating system. Unix was never written in B.
4
Photo from http://techchannel.att.com/play-video.cfm/2012/2/22/AT&T-Archives-The-UNIX-System
COP3353
Brian Kernighan
Introduction to Unix
Unix – Small Beginnings Pg 4
“New B” or “NB” – a Little Higher Language
In 1970, Ritchie improved B enough to give it a new name: “New B” (or “NB”). The
motivation for NB was the new PDP-11 that Bell Labs bought for the newly officialized
Unix project. This machine was much more advanced than the PDP-7, more than even
the older mainframes, because it supported a new data type – the character. The
original B was typeless; to it, everything was an integer.
Ritchie added new data types, increased functionality a bit, and wrote a compiler for NB.
The compiler didn't create machine code, but object code that was more efficient for the
interpreter. New B was a step closer to being useful.
“C” – Eureka!
In 1971-1972 Ritche and Brian Kernighan evolved New B
so much, it deserved a new letter – C. It had a compiler
that produced machine code, full data types for variables,
and structures for complex data types; it was complete
enough to write an operating system.
In the summer of 1973 the Unix kernel (the core OS
functionality) for the PDP-11 was rewritten in C.5
Around this time, a need arose to port Unix to the
Honeywell 635 and the IBM 360. For this, Mike Lesk
wrote the “portable I/O package” which would become
the C “standard I/O” routines.
Dennis Ritchie (standing) and Ken Thompson
begin porting UNIX to the PDP-11 via two
Teletype 33 terminals, 1972.
The First Unix Application
How did the Unix team convince Bell Labs to spend over a half-million dollars for
a new PDP-11? They promised to build a word processor for the patent department. They achieved this, supporting three typists typing, editing, and formatting
patents (using tools written in-house), while at the same time supporting the Unix
team's work, all on a single minicomputer.
Kernighan & Ritchie's book
defined standard “K & R” C
5
Photo: http://cm.bell-labs.com/cm/cs/who/dmr/picture.html
COP3353
Introduction to Unix
Unix – Small Beginnings Pg 5
The Command Line, I/O Redirection, and Piping
Small Kernel, Lots of Utilities
One reason Multics was so bulky was that too much functionality was put into the
“kernel”, the core of the operating system. Thompson made the Unix kernel small by
making it do as little as possible; much of Unix's functionality occurs through hundreds
of small, independent, single-purpose utility programs like cp to copy files, and sort for
sorting them. (See http://en.wikipedia.org/wiki/Linux_commands)
These utilities take their input from the “standard input” device (the keyboard by default)
and send output to the “standard output” device (the printer or monitor by default).
Piping & Redirection – Making Utilities Work Together
The problem was how to make all these utility programs work together. This was a
question that had seen several complex solutions.
Doug McIlroy6 had played with sending output of one program to the input of another so
data would stream from one to the next, “screwing together streams like garden hoses”.
At the time “I/O redirection” was common – sending the output of a command to a
destination other than the screen:
ls > myFile
ls
>
myFile
Command to show the files in a directory.
“Redirection” operator to divert output to a file instead of the screen.
The new destination for the output – write the output to this file.
McIlroy had worked since the early 1960's on a way to redirect output to another
command instead of to a file:
ls > sort > myFile
It was tricky to distinguish files from programs – Does ls > sort mean to write the
output of ls to a file named sort, or to send it to the input of the sort program?
Maybe this would work:
sort(ls) > myFile
Too non-linear – people stumble over it. For years, different syntaxes were tried, but none
worked.
6
McIlroy photo: http://www.cs.dartmouth.edu/~doug/
COP3353
Doug McIlroy
Introduction to Unix
Unix – Small Beginnings Pg 6
The Pipe Operator – The Right Idea
Then McIlroy and Thompson hit on the idea for a new operator: the “pipe”:
ls | sort > myFile
|
>
“Pipe” operator redirects output of one program to the input of another program
“Redirection” operator to divert output to or from a file.
•
What goes before and after the “pipe” character are programs; the output of the
first program goes to the input of the second.
•
The “>” character moves data to or from a file.
Programs go on
both sides of a
pipe.
McIlroy's garden hoses had become pipes.
Command Line Tools
This changed the nature of command line programs. Programs like ls and sort were
“tools” that worked together. You strung them together to do things that no single tool
could do alone. This is the tools approach to the command line.
The Unix Philosophy
There's an explicit philosophy behind Unix:
Make everything as small and simple as possible
•
•
•
•
•
Move as much functionality as possible out of the kernel and into supporting
programs.
Design all supporting programs to perform a single purpose.
Perform complex tasks by piping simple tool together.
Treat all I/O the same, in units of bytes, as though it were text.
Treat all devices the same, as though they were files.
Ironically, the credit for this simplicity goes to Multics – Unix's leanness and simplicity
comes from the painful experience with Multics' girth and complexity.
Sam Morgan, director of Bell Labs Computing Science Research:
"if you order an operating system [from] a group of programmers, you get
Multics. If you leave them to their own resources and imagination, things like
Unix will grow out of their creativity."
A large team designed Multics on paper for a year before the first line of code was
written. Unix was written to scratch an itch.
COP3353
Unix came from
the “hacking”
school of
software design.
Introduction to Unix
Unix – Small Beginnings Pg 7
For More Unix History:
The Creation of the UNIX Operating System: http://www.bell-labs.com/history/unix/
The UNIX Oral History Project: http://www.princeton.edu/~hos/Mahoney/expotape.htm
https://www.princeton.edu/~achaney/tmve/wiki100k/docs/B_(programming_language).html
http://www.i-programmer.info/history/computer-languages/472-part-2-the-1960s.html
Development of the C Language: http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
http://www.fact-index.com/b/b_/b_programming_language.html
http://cm.bell-labs.com/who/dmr/hist.html
COP3353