Live data from Hacker News

Newly discovered earliest draft of a Unix manual (1971)

tuhs.org

21–30 of 42 posts

Re: Newly discovered earliest draft of a Unix manual (1971)

#21
post #12

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... 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)'.)

It was also previously submitted (without discussion) 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!

Re: Newly discovered earliest draft of a Unix manual (1971)

#22
"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.

Re: Newly discovered earliest draft of a Unix manual (1971)

#23
post #17

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.

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

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".

Re: Newly discovered earliest draft of a Unix manual (1971)

#24
post #23

Earlier quoted context omitted.

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

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".

  > 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”.

Re: Newly discovered earliest draft of a Unix manual (1971)

#25
post #23

Earlier quoted context omitted.

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

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".

'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.'

Catenate and concatenate mean basically the same thing, it's trivially easy to see people confusing the two - they might even hear one for the other if they're only familiar with one. That's not going to happen with catharsis.

Re: Newly discovered earliest draft of a Unix manual (1971)

#26
post #2

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

It's not an OCR error - the error appears in the original. If you look at Page 8 of the scanned PDF[1], it says:

  filep = create(name, mode)
[1] http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc...

Re: Newly discovered earliest draft of a Unix manual (1971)

#27

"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…

Um, structs?

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

wait_t status = wait();

Re: Newly discovered earliest draft of a Unix manual (1971)

#28
"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."

Re: Newly discovered earliest draft of a Unix manual (1971)

#30

"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…

Um, structs? typedef struct { pid_t pid; int status; } wait_t; wait_t status = wait();

Tuple support, which in essence are anonymous structs, would have been very nice in C, too.
Post reply on HN