Reviving the 1973 Unix Programmer's Manual

Re:Reviving the 1973 Unix Programmer's Manual by xelxebar on Monday November 20, 2017 @03:39AM (#15738641)

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.

[ Parent | on HN ]

Re:Reviving the 1973 Unix Programmer's Manual by groovy2shoes on Monday November 20, 2017 @04:37AM (#15738809)

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

[ Parent | on HN ]

Re:Reviving the 1973 Unix Programmer's Manual by xelxebar on Monday November 20, 2017 @05:31AM (#15738994)

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.

[ Parent | on HN ]

Re:Reviving the 1973 Unix Programmer's Manual by bandrami on Monday November 20, 2017 @09:14AM (#15739950)

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

[ Parent | on HN ]