3 ms·

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

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

xelxebar 9y ago
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)

xelxebar 9y ago

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)