Hacker News Reader

Comment by Koshkin | Hacker News Reader

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

View on HN

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)

Reply on news.ycombinator.com