Learning about "The Unix Time-Sharing System" | Hacker News Reader

Learning about "The Unix Time-Sharing System"

playtechnique.io

I'm the writer of this essay.

My subject is some details surrounding the first white paper that Bell Labs published about Unix was "The Unix Time-Sharing System". I wrote what Ken Thompson was doing in between the end of Multics but before he found the "little used PDP-7" that he wrote Unix on, the difference between opening files on Multics and Unix, and what the "comfile" mentioned in the paper is.

I wrote this without AI involvement; I follow Unix history because I love knowing what the history is and what I can learn from it, and I love showing others these sorts of cool details.

I'd love to hear any feedback you might have :)

> So what's a comfile? Clearly it's a shell script, yeah? So why're they called comfiles? It's short for "command files".

The vestige I'm amused by on my (BSD) systems is <foo>.S files. "S" for "Source". From the time when "source code" meant "assembly". Python, zig, C++, C, etc would be invented later...

I <3 the BSDs, and they're the reason that the quote from "A Research Unix Reader" stuck in my memory! I started on the linuxes, pre-systemd by many years, and remember system v init levels seeming straightforwards but weird. When I switched to FreeBSD and saw /etc/rc.local, it made far more sense to me. I never even _thought_ about what 'rc' might mean, though.

Seeing the quote from Doug McIlroy many years later lodged in my brain as answering a question I didn't even have, and I've been looking for a good reason to use it ever since.

There's a lot of cool small details like that in so many early white papers about Unix; I'm looking forwards to working through a good number of them over the next 12 months. I think next I'll look at Dennis Ritchie's paper on the impact of migrating Unix from assembly to C. It may give me good opportunity to cover the B->C change as background, which is fascinating to see.

Was C really later? I thought UNIX had been ported before it made it to Berkeley.

C wasn't _later_, but perhaps you're misrecalling when Thompson had his Berkley sabbatical?

The quickest source I can find this moment for my claim is an interview with Ken Thompson in IEEE magazine called "Unix and Beyond: An Interview with Ken Thompson". Here's the quote, "At one point, I took BCPL from Martin Richards at MIT and converted it into what I thought was a fairly straight translation, but it turned out to be a different language so I called it B, and then Dennis took it and added types and called it C." You can read the whole thing at https://ieeexplore.ieee.org/document/762801 (or https://www.cs.princeton.edu/courses/archive/spring03/cs333/... if you prefer plain text).

When I write the newsletter, I'm _fairly_ sure one of Thompson's big interviews on YouTube has him call this out more clearly, but if I'm misrecalling I'll be sure to write exactly what I can figure out and where I'm sourcing the ideas from.

The specific Dennis Ritchie essay that I was referring to, though, is https://www.nokia.com/bell-labs/about/dennis-m-ritchie/portp... - "Portability of C Programs and the UNIX System". He coauthored it with Stephen Johnson, who can count Yacc amongst his many contributions to Unix.

My vague recollection is that the kernel in Unix v2 (still called UNIX in those days) was written in assembly language, but that many of the commands were written in B. Because B was interpretive on the PDP-11 (it suffered from the same problem as BCPL, in that it expected a word-addressed machine), it would have been impractical to use it in the kernel. If I recall correctly, the first Unix to reach Berkeley was some kind of v2.

The C compiler appeared in v3, and the kernel rewrite happened for Version 4, which is the version described in the paper.

Using .S for assembly language source is a historical accident, by the time the majority of code was written in C, .a was defined as the conventional filetype for archive (ar) files.

The timeline you're presenting matches what I recall, also. Nice!

That tidbit about .S vs .a is a lovely detail. "A Research Unix Reader" has other cultural details called out that're similar - https://doc.cat-v.org/unix/unix-reader/A.Research.Unix.Reade.... Two of my favourites are the idea that originally a shell script couldn't be part of a pipeline ("programs that were likely to read from shell scripts, especially sh and ed, were made to read their input one character at a time. It was impossible to pipe into a shell script because the standard input was already dedicated to the script. For the same reason a program in a shell script could not take input from a terminal except when given the terminal’s real name.") and this note from the man page for sort v1:

> A bug note in join(1) declares, ‘‘The [field-specification] conventions of join, sort, comm, uniq, look and awk(1) are wildly incongruous.’’ Although these programs are often used together, they remain, like American weights and measures, sturdily eccentric.

I remember thinking that commands were weirdly unsimilar as I was first learning them; it took this many years for me to see one of the early authors wrote an oopsie about them :)

Right - I mentioned BSD because it’s what I run/am-familiar-with, and it does have *.S files [0], but those (or at least the naming convention) came from pre-existing AT&T Unix - so my example does indeed use BSD[1] first released 1978, which is after C[2], created 1972, but The Original Unix[3] (of which BSD is but an embodiment) was started in 1969, before C.

[0] https://cdn.netbsd.org/pub/NetBSD/NetBSD-release-9/src/sys/a...

[1] https://en.wikipedia.org/wiki/Berkeley_Software_Distribution

[2] https://en.wikipedia.org/wiki/C_(programming_language)

[3] https://en.wikipedia.org/wiki/Unix

Reply on news.ycombinator.com