Hacker News Reader

Comment by dfabulich | Hacker News Reader

> The text of the manual was written using the ed text editor.

I guess I should have known, but I had no idea that anyone had written a 50,000-word 300-page manual in ed. It has a bit of a, uh, reputation.

https://www.gnu.org/fun/jokes/ed-msg.txt

View on HN

There was a time when a civilized person could sit down and write out a letter (or an essay) longhand, in ink, without making a blot of it. A few overstrike corrections were normal. I've written many Telcomp programs on an ASR33 back in the day using something like ed and thought it was great stuff.

"Edsger W. Dijkstra on Dutch TV":

https://www.youtube.com/watch?v=RCCigccBzIU&feature=youtu.be...

I always find all the old programming humor some of the funniest stuff around and people will look at me and ask what are you laughing about but the humor is always lost on them.

The bit about error reporting was the best part.

> Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.

Ed will error a lot and not give you meaningful reasons as to why it errored

> not give you meaningful reasons as to why it errored

i.e., ?

In 1986 or 1987 as a part of after school lessons I got access to a Soviet clone of IBM 360. Initially the only editor was something very similar to ed. After few hours I felt very comfortable with it. Typing programs in it felt like cool hacking. But then after an upgrade we got a screen editor. It was so much better with moving cursor around and updating/fixing PL1 sources. But the feeling of hacking disappeared.

What kind of "reputation"? It is quite usable for typing in text. Hell, even

  cat > myfile.txt << EOF

works fine in many situation. Sure, if one can't think straight, makes a lot of typos and errors that cannot be quickly fixed with a simple backspace, needs a lot (and I mean a lot) of complicated refactoring to be done many times over, then sure - ed is not for them. (Also, do not forget ed's close cousin - sed, a "stream editor" that is widely used even today.)

I'd like to think that programmers back then most likely "graduated" from using punch cards, hence they have a higher mental guard against typos and mistakes when writing their program (or essays), compared to programmers that grow up with unlimited undo/redo. Back then if you had a typo you'd most likely have to wait overnight, or even days to get the notice so you spend a lot of time proofreading your text, and over time it becomes a second nature to write something right (most of the time).

Back in the day you wrote your program on paper and sent it to the punch operators

Just fyi, you don't actually need the heredoc. This works just as well:

    cat > myfile.txt

You can terminate input by sending ascii EOT (Ctrl-D). It makes sense once you realize that heredocs are just a way of explicitly setting the contents of stdin. By not using a heredoc, cat opens stdin and writes it through to 'myfile' or wherever until stdin gets closed, which the terminal driver does for us when we send EOT.

There is a bit of a difference, though: if your shell has line-editing facilities (readline, libedit, and the like), they're available within the heredoc, but almost certainly not available on cat's stdin.

I suppose it's possible to have a version of cat that offers line-editing, but I'm not aware of one (nor do I think it's a particularly good idea to make one, "unix philosophy" and all that). Slap it into an rlwrap, maybe ;)

This is a good point. Options and flags aside, GNU coreutil's cat reduces essentially to a simple while loop around 'read' and 'write'. So without the heredoc read blocks until stdin contains characters. IIRC, the input here is just controlled by the kernel line discipline, a far cry from readline and friends, as you mention.

Actually, I'm confused on how the kernel knows to associate keyboard input with any particular file at all. If we have several terminals open, then presumably there are several ttys to which keyboard events could eventually propogate to. There's gotta be some way to mark which file a line buffer writes to.

> I'm confused on how the kernel knows to associate keyboard input with any particular file at all

If you're running a graphical environment, it doesn't: the kernel hands the keypress events to X or to Wayland, and they are then responsible for multiplexing them (X uses the focus capabilities in Xlib; I haven't poked around much with Wayland but it must do something similar).

If you're on the console in Linux, there's a set of ioctls[1] that control how the kernel multiplexes virtual terminals. These can be set by the userland utility chvt. (Other Unixes do this differently; e.g. NetBSD and OpenBSD make a wsconsole abstract device with syscalls to associate it with a given TTY.)

1: https://linux.die.net/man/4/console_ioctl (scroll down to VT_ACTIVATE for the relevant parts)

    -rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

Yeah, now I want to see he talking about GNU ls and the -h option.

"> The text of the manual was written using the ed text editor."

From where are you quoting this? I don't see it in TFA.

From the rendered manual that is linked from TFA

https://dspinellis.github.io/unix-v4man/v4man.pdf

> This manual was set by a Graphic Systems phototypesetter driven by the troff formatting program operating under the UNIX system. The text of the manual was prepared using the ed text editor.

Thanks. I was looking on the linked site and the README in the repo.

Honestly ed is mostly fine, especially on those old computers. It's basically just the line-based predecessor of vi

The line-based predecessor of vi is more properly ex (Bill Joy wrote a VIsual mode of his EXtended editor), which was designed to work in the same regime as ed, but wasn't really compatible. Ex is just vi's command mode. Ed is... different.

What else would you write it in at the time? When you have a TeleType you can't exactly use a visual text editor, can you?

Reply on news.ycombinator.com