4 ms·

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 r

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.

bandrami 9y ago
> 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 https://linux.die.net/man/4/console_ioctl (scroll down to VT_ACTIVATE for the relevant parts)