
Newly discovered earliest draft of a Unix manual (1971) - jritorto
http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/UnixEditionZero.txt
======
dang
Doug McIlroy on what this is and why it is remarkable (thanks to knome for
this explanation):

[http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc...](http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/Readme)

This is amazingly cool and clearly deserves more attention, so we've changed
the title and re-upped the submission to give more people a chance to see it.

(Submitted title was 'DMR Unix “Edition Zero” Manual Unearthed (restoration in
progress)'.)

~~~
LukeShu
It was also previously submitted (without discussion)
[https://news.ycombinator.com/item?id=10660727](https://news.ycombinator.com/item?id=10660727)

Perhaps change the URL to the directory, so people can see the Readme and
image scans, without needing to come here to the comments?

I'm glad it's getting attention now!

------
luckydude
Is it just me or are the comments here missing the point? This is the original
writeup of Unix. It's amazingly well written and pretty complete for when it
was done. This is v0 of Unix, it's barely started.

You could, and people did, write a lot of code with just that doc as
documentation.

Maybe it's because I'm a Bell Labs fanboy, I find this doc impressive.

~~~
pteredactyl
100% agree on impressiveness. Great to see the architecture in its nascent
form.

------
aplorbust
"The most important role for UNIX is to provide a file system."

I looked up TGM which is mentioned in this manual (TGML). Apparently this was
what Thompson used to write the B compiler.

Anyway, I ended up on the Multicians site. Some online accounts of computing
history suggest UNIX was an alternative to the Multics project.

On the Multicians site it suggests Multics had a very different concept of
"files", which could also be "segments". There was apparently potential
ambiguity regarding the term "file".

Here's my question for anyone who was there:

Today we often see the phrase "Everything is a file" being cited when
introducing people to UNIX. But I have never seen anyone attempt to explain
why. What was the context in the 1970's?

Was the UNIX notion of "files" a reaction to the approach taken by Multics?

Again, this early manual says: "The most important role for UNIX is to provide
a file system."

~~~
nickpsecurity
"On the Multicians site it suggests Multics had a very different concept of
"files", which could also be "segments". There was apparently potential
ambiguity regarding the term "file"."

Segments are a hardware mechanism often used then for accessing or protecting
things in memory due to simplicity & speed of mechanism. Several modern
techniques in INFOSEC use segments to protect programs.

Here's how the MULTICs filesystem worked, though. Gist of it seems like
MULTICS came up with all the key concepts I recognize for hierarchical,
filesystems.

[http://www.multicians.org/fjcc4.html](http://www.multicians.org/fjcc4.html)

Hansen's history shows the Titan System also had a similar filesystem:

[http://brinch-hansen.net/papers/2001b.pdf](http://brinch-
hansen.net/papers/2001b.pdf)

Both predate UNIX with Thompson and Ritchie actually using MULTIC before
writing UNIX. So, it's probably main influence.

"Today we often see the phrase "Everything is a file" being cited when
introducing people to UNIX. But I have never seen anyone attempt to explain
why. What was the context in the 1970's?"

It's explained here:

[https://superuser.com/questions/364152/why-is-everything-
is-...](https://superuser.com/questions/364152/why-is-everything-is-a-file-
unique-to-the-unix-operating-systems)

More detail from authors (see 3.3):

[http://www.scs.stanford.edu/nyu/04fa/sched/readings/unix.pdf](http://www.scs.stanford.edu/nyu/04fa/sched/readings/unix.pdf)

"Again, this early manual says: "The most important role for UNIX is to
provide a file system.""

Ritchie was clear in other writings that there wasn't a single goal for UNIX
at all other than to be usable and more than what they were working with. It
was designed to be efficient and enable programmers rather than hold them
back. The rest fell into place from there.

~~~
aplorbust
I can appreciate the response from "alvin" in the superuser comments.

Too bad networking was not part of early UNIX; sockets could perhaps have been
part of the "carefully selected set of fertile ideas" that could be "keys to
the implementation of a _small_ yet powerful operating system."

"carefully selected" (i.e., things are deliberately left out)

"small" (i.e., smaller than the alternatives)

These are ideas in programming that seem to have been lost over time.

~~~
nickpsecurity
Yeah, it's unfortunate. There were a number of systems in the past that got
very clever with networking and it made everything easier for
developers/users. Mostly happened in the 1990's. Most are aware of Plan 9.
More interesting were Amoeba distributed OS and Convergent's CTOS. The CTOS
was a commercial, alternative to mainframes that distributed the system among
cheaper computers. Had a lot of take-up before it was canned by Unisys after
an acquisition. Couldn't have innovative products threatening their mainframe
profits. ;)

[https://en.wikipedia.org/wiki/Amoeba_%28operating_system%29](https://en.wikipedia.org/wiki/Amoeba_%28operating_system%29)

[https://en.wikipedia.org/wiki/Convergent_Technologies_Operat...](https://en.wikipedia.org/wiki/Convergent_Technologies_Operating_System)

~~~
aplorbust
Amoeba was mentioned toward the end of the Hanson paper you cited above. I
have read about Convergent in the past, but had not read the Hanson paper.
Thank you for that.

------
teddyh
Why does this supposedly old file contain UTF-8 encoded characters? (The
apostrophe in “ _search in the user’s current directory_ ” is U+2019, RIGHT
SINGLE QUOTATION MARK.)

~~~
knome
It's not an old file. It's a new file resulting from running OCR on a PDF of a
physical manual. Clipping off the filename in the original URL, you'll find a
directory [1] with an explanation in the README [2]

[1]
[http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc...](http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/)
[2]
[http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc...](http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/Readme)

~~~
dang
Thank you, that's a critical bit of context.

~~~
lisper
Indeed, and it's a good illustration of a flaw in the HN comment ranking
algorithm: this "critical piece of context" is at the bottom -- and likely
will stay there -- because it's the child of a heavily downvoted comment.

~~~
oneeyedpigeon
So include it in a new top-level comment and everyone wins.

------
c3534l
Reading this manual describe concepts without the use of computer jargon as
brand new concepts makes the language sound really old-fashioned, like reading
Jonathon Swift or Thomas Paine. Part of that, I'm sure, is that this document
is now 45 years old. It kind of makes me want to go back and read the
instruction manual that would have come with the first TVs and such.

------
kryptiskt
"The third and last process control system call used by the Shell is

    
    
          processid, status = wait()
    

This primitive causes its caller to suspend execution until one of its
children has completed execution. Then wait returns the processid of the
terminated process and a status value indicating how the process died.
(Processes which are never waited for die unnoticed and presumably
unmourned)."

A lost opportunity to give C multiple return values.

~~~
luckydude
Um, structs?

typedef struct { pid_t pid; int status; } wait_t;

wait_t status = wait();

~~~
sebleblanc
Tuple support, which in essence are anonymous structs, would have been very
nice in C, too.

------
solidsnack9000
> ...an output file other than the typewriter was provided...

Those were the days.

------
ape4
Unix has made our lives much more pleasant.

------
onre
Fascinating. No pipes yet!

------
geofft
This should put to rest the persistent, pedantic hypercorrection that the
"cat" command is so named because it "catenates" files as opposed to
concatenating them.

~~~
dllthomas
Don't get your hopes up - it seems to remain possible the abbreviation
preceded this document and was misattributed by Richie.

~~~
geofft
OK, but at that point it's equally possible that it stands for "catharsis" and
represents a file, previously being kept inwardly on disk, being released to
standard output. The command doesn't predate UNIX, so it's a very narrow
window of time for Ritchie to have gotten it wrong. And I have not seen any
claims from the 1970s or 1980s that the command stands for "catenate".

~~~
kps

      > And I have not seen any claims from the 1970s or 1980s
      > that the command stands for "catenate".
    

The Seventh Edition (1979) man page for cat(1) says “catenate and print”.

Sixth Edition (1975) says “concatenate and print”.

~~~
LukeShu
This made me do my own investigating. The `csh` manual in 2BSD said "catenate"
earlier in '79\. Even before that, a comment in the ex (vi) 1.1 source code in
1BSD (1978) says "catenate".

So it looks like Bill Joy made the mistake! (and the Bell Labs people thought
it funny?)

------
AndyMcConachie
> Commands need not be on different lines; instead they may be separated by
> semicolons.

Is that a joke?

~~~
coldtea
What part of it sounds like a joke? That's how it is today too, but it wasn't
the case at the time for all environments.

~~~
AndyMcConachie
The use of a semicolon in the preceding sentence is what I thought might be
the joke. Read the sentence again, Dennis's use of a semicolon is a rather
strange way to punctuate the sentence.

------
gamache
There must be some OCR errors in there -- the system call "create" was spelled
with an "e"!

~~~
mpweiher
Sure about that?

    
    
       CREAT(2)                    BSD System Calls Manual                   CREAT(2)
    
       NAME
            creat -- create a new file
    
       LIBRARY
            Standard C Library (libc, -lc)
    
       SYNOPSIS
            #include <fcntl.h>
    
            int
            creat(const char *path, mode_t mode);
    
       DESCRIPTION
            This interface is made obsolete by: open(2).
    
            The creat() function is the same as:
    
                  open(path, O_CREAT | O_TRUNC | O_WRONLY, mode);
    
       SEE ALSO
            open(2)
    
       HISTORY
            The creat() function appeared in Version 6 AT&T UNIX.
    
       BSD                              June 2, 1993                              BSD

~~~
lambda
I think he's saying that in this document, "creat" is sometimes spelled with
an "e", indicating that the OCR process overcorrected.

    
    
      3.5.2 Create
      
      To create a new file, the following call is used.
      
           filep = create(name, mode)

