7 ms·
Newly discovered earliest draft of a Unix manual (1971)
- gamache 11y agoThere must be some OCR errors in there -- the system call "create" was spelled with an "e"!
- deleted 11y ago[deleted]
- mpweiher 11y agoSure 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
- rst 11y agoYou're missing the joke -- the recovered "Unix 0" manual seems to spell it 'create', even though it was 'creat' in subsequent versions.
- ksherlock 11y ago3.5.2 Create To create a new file, the following call is used. filep = create(name, mode) But it's listed correctly as a system call. A1.6 creat To create or recreate a file, sys creat name mode
- lambda 11y agoI 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)
- krylon 11y agoWell, there's this quote by Ken Thompson, who was asked if he'd do anything different if were to start over on Unix: "I would spell creat with an e". With that in mind, it's kind of funny to see that "correction" made by some OCR software.
- greenyoda 11y agoIt'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/McIlroy_v0/UnixEditionZero-OCR.pdf http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc...
- teddyh 11y agoWhy 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 11y agoIt'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/McIlroy_v0/ http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc... [2] http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/Readme http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc...
- dang 11y agoThank you, that's a critical bit of context.
- lisper 11y agoIndeed, 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 11y agoSo include it in a new top-level comment and everyone wins.
- luckydude 11y agoIs 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 11y ago100% agree on impressiveness. Great to see the architecture in its nascent form.
- dang 11y agoDoug 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/McIlroy_v0/Readme 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)'.)
- LukeShu 11y agoIt 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!
- onre 11y agoFascinating. No pipes yet!
- ape4 11y agoUnix has made our lives much more pleasant.
- geofft 11y agoThis 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 11y agoDon't get your hopes up - it seems to remain possible the abbreviation preceded this document and was misattributed by Richie.
- geofft 11y agoOK, 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 11y ago> 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 11y agoThis 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?)
- dllthomas 11y ago'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.
- c3534l 11y agoReading 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 11y ago"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 11y agoUm, structs? typedef struct { pid_t pid; int status; } wait_t; wait_t status = wait();
- sebleblanc 11y agoTuple support, which in essence are anonymous structs, would have been very nice in C, too.
- aplorbust 11y ago"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 11y ago"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-a-file-unique-to-the-unix-operating-systems https://superuser.com/questions/364152/why-is-everything-is-... 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.
- AndyMcConachie 11y ago> Commands need not be on different lines; instead they may be separated by semicolons. Is that a joke?
- coldtea 11y agoWhat 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 11y agoThe 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.
- solidsnack9000 11y ago> ...an output file other than the typewriter was provided... Those were the days.