BSD vs. SVR4 typehead flush after tty mode change

[Guy Harris]

>It sems to me that a bug was introduced in the kernel solely in order
>to avoid fixing the C shell, which is clearly screwed up in its input
>handling.  In interactive command-line editing mode, a shell should
>read() only 1 character at a time.

I won't defend the unnatural acts the C shell engages in to implement
"filec",

BUT

that's not *the* problem with switching modes, it's just the most
*obvious* one.

Consider a more vanilla shell, one that runs in cooked mode.  You type
some characters while exiting some program that runs in uncooked mode,
those characters being typed while still in uncooked mode.  As such,
they probably went upstream immediately and are sitting at the stream
head.

Let's say you're typing the command "cat /etc/motd", and you, say,
manage to type "cat /ect/" (*sic*) before the driver is switched to
cooked mode.  You realize you got it wrong, and type your kill character
to try to erase the entire line and start again (or, this being S5R4,
type the word-erase character).

Well, the "cat /ect/" has already left "ldterm"s domain, so it *can't*
be erased by ^U (or ^W).  It is, again, just as if you'd typed

	c^Da^Dt^D ^D/^De^Dc^Dt^D/^D

Probably the "best" fix for this problem is to have "ldterm", when in
uncooked mode, *never* send anything upstream unless it's been
requested.  This does, of course, require some way of dealing with the
"poll()" problem, which probably means a message sent downstream when
the "poll()" is done (only if the stream has M_READ notification turned
on), and another message sent upstream in lieu of data to indicate that
a "poll()" waiting for input to succeed.  Unfortunately, that would
require more stuff to be added to the stream head code....