If you do:
stty eol =
And then run the demo suggested in your EDIT, you will see foo bar in the printout of test.out. The terminal's line discipline will flush its output to its reader as it reads each special eol char in your input.
A Linux canonical-mode terminal - as can be configured with
stty icanon or probably just
stty sane - handles the following special input characters...
- Terminates an input line and flushes output to the reader. Because it is removed from input, if it is input as the only character on a line, it is passed as a null read - or end of file - to the reader.
- default: unsassigned
- Also terminates an input line, but is not removed from input.
- Erases all buffered input.
^H (or possibly
^? on some systems)
- Erases the last buffered input character.
When iexten is also set - like
stty icanon iexten or, again, probably just
stty sane, a canonical Linux terminal will also handle...
- default: unassigned
- Also also terminates an input line, and is also not removed from input.
- Erases the last buffered input word.
- Reprints all buffered input.
- Removes any special significance as far as the line-discipline is concerned for the immediately following input character.
These characters are handled by removing them from the input stream - excepting eol and eol2, that is - and performing the associated special function before passing the processed stream to the reader - which is usually your shell, but could be whatever the foreground process group is.
Other special input characters which are similarly handled but can be configured independently of any icanon setting include the isig set - set like
stty isig and probably also included in a sane configuration:
- Flushes all buffered input (if noflsh is not set) and sends SIGQUIT to the foreground process-group - likely generating a core-dump.
- Flushes all buffered input (if noflsh is not set) and sends SIGTSTP to the foreground process-group. The suspended process-group can likely be resumed with either of
kill -CONT "$!" or just
fg in a (
set -m) job-controlled shell.
- Flushes all buffered input (if noflsh is not set) and sends SIGINT to the foreground process-group.
And the ixon set - configured like
stty ixon and also usually included in a sane config:
- Stops all output to the reader until either start is read in input or - when ixany is also set - at least one more character is read.
- Restarts output if it has previously been stopped with stop.
- Both of stop and start are removed from input when processed, but if output is restarted due to any character in input when ixany is set then that character is not removed.
Special characters handled on other non-Linux systems might include...
- Toggles the discarding and flushing of buffered input and is removed from input.
- default: unassigned
- Flushes all buffered input only when the reader reads the assigned special input character then sends SIGTSTP.
- Switches foreground shell-layers. For use with the
shl shell-layers application on some systems.
- An implementation of
shl which multiplexes ptys and is therefore compatible with job-control rather than the original implementation's swtch dependent behavior can be freely had in the
heirloom-toolchest tool suite.
For a clearer picture of how and why (and perhaps why not) these input functions are handled consult
man 3 termios.
All of the above functions can be assigned (or reassigned) - when applicable - like
function assigned-key. To disable any single function do
^-. Alternatively, as various attempts with assignments for any of the aforementioned line-editing functions with all of GNU, AST, or heirloom's
stty implementations seem to indicate, you can also
^@ as NUL assignment for any function seems to equate to setting it to unassigned on my linux system.
Probably you do see an echo of these characters when you type them (as can likely be configured w/ [-]ctlecho), but this is only a marker to show you where you did - the program receiving your input has no notion that you typed them (excepting eol, that is) and receives only a copy of your input to which the line discipline has applied their effects.
A consequence of the terminal's handling of the various line-editing functions is that it must needs buffer the input to some extent in order to act upon the functions you indicate to it that it should - and so there cannot be a limitless supply of input which you might at any time kill. The line buffer is more precisely the kill buffer.
If you set the eol or eol2 characters to some delimiter which occurs in input - even if neither is a newline or a return character, for example - then you will only be able to kill up to the point that it last occurred and your kill buffer will extend as far as it can until the next of these - or a newline (or return if icrnl is set and igncr is not) - occurs in input.