BSD vs. SVR4 typehead flush after tty mode change

[Guy Harris]

 >>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.
 >
 >If I am not mistaken I remember noting this same problem with
 >switching from non-canonized processing to canonized processing under
 >the old (non streams) tty subsystem.  Ie, this is not a new problem.

I think you're mistaken.  I've never noted any such problem with either
the old BSD tty subsystem or the old S5 tty subsystem.

The old BSD tty subsystem will, if you switch from CBREAK mode to
non-CBREAK mode, take everything in the raw queue and shove it through
the input-processing machine.  (If you switch from RAW mode to non-RAW
mode, it discards queued input.)

The old S5 tty subsystem leaves stuff in the raw queue until you
actually try to read it, at which point it calls "canon()" and moves
stuff in the raw queue to the canonical queue after doing canonical
processing.

In both cases, characters typed in noncanonical mode are under the
control of the line discipline until they're actually read by a process,
and are in the raw queue, so that they can be erased if canonical mode
is turned on.

>It also seems to me that flushing the stream when ICANON is turned
>on may fix this problem for csh, but breaks typeahead (for programs
>that go in an out of ICANON)

Yes, that's the complaint that started this thread in the first place; I
don't like it, but short of arranging that characters typed in
noncanonical mode remain under the control of "ldterm" until they're
actually read by a process, as is the case in non-streams tty drivers
and as I suggested be the made the case with the streams tty driver, you
have the problem I described.  I don't like having typeahead discarded,
either, but....

In order to arrange that characters typed in noncanonical mode remain
under the control of "ldterm" until they're read, you need:

	1) M_READ: SunOS 4.x doesn't have it, but S5R4 does;

	2) M_POLL - i.e., if a "poll()" for input is done on a stream
	   with no data at the stream head but with M_READ notification
	   turned on, a message is sent downstream; if there is data
	   that would have been send upstream in response to an M_READ,
	   a reply is sent upstream to the M_POLL that causes it to
	   succeed, and if there isn't any data, the fact that a
	   "poll()" is in progress is noted, so that when data *does*
	   come in, the reply can be sent upstream to wake up any
	   "poll()"ing processes.  Neither SunOS 4.x *nor* S5R4 have
	   this, as far as I know.

All that stuff doesn't necessarily help if you have a user-mode
canonicalizer that can get out of the way if canonicalization is turned
off, e.g. a "cmdtool" window or an Andrew Toolkit "tm" window.

The problem there is that the "cmdtool" or "tm" or whatever program
would have to withhold any characters typed at it when canonicalization
is turned off, and listen for M_READ or M_POLL messages sent down the
slave side (the S5R4 pseudo-tty mechanism would let this happen, as long
as the appropriate pseudo-tty streams modules and driver pass it through
to the master side).  If such a message arrived, it would cough up the
requested number of characters (if an M_READ) or a reply (if an M_POLL).

If the program detected that canonicalization is turned on, it would
have to take all the queued-up characters and act as if they'd been
typed at it in canonical mode.

Programs like that get in the way of a number of things (including the
filename completion stuff the C shell does, and which I mentioned
earlier).