VT100 terminfo problem

[Guy Harris]

> Most UNIX VT100 users who have flow control problems have failed
> to execute "stty ixon -ixany" in their .profile or other means
> of setting up terminal parameters when logging in.

Note that when Doug said "-ixany", he meant it!.  VT100s prefer the host to
strictly obey the ^S/^Q conventions, and not turn output back on just because
they received a character.  ("ixon" is generally set by default on systems with
an S3/S5-style "ioctl" interface, which is the one for which "ixon" and
"-ixany" are the proper settings.)

> Older UNIX systems made this hard to do since switching out of fully-cooked
> mode would also disable flow control.  Modern ones do have the capability of
> retaining flow control when switching modes.

Just about all versions of UNIX out there are "modern" in this sense, as long
as you switch into "cbreak" mode, rather than "raw" mode, on systems that have
the V7-style "ioctl" interface.  Systems with a V6-style interface lost, but
then those systems may not have had ^S/^Q flow control anyway.  "raw" mode was
generally intended for binary data transfers (e.g., UUCP), while "cbreak" mode
was what was to be used for "full-screen" interactive applications (e.g.,
"vi").  The *ONLY* time "raw" mode should be used for "full-screen" interactive
applications are those times when:

	1) the system has only a V7-style "ioctl" interface;

	2) the application needs an 8-bit path to the terminal (e.g., EMACS on
	   terminals with a "meta" key that sets the 8th bit on characters);

	3) there is no "pass8" mode (as there is in 4.3BSD).

	4) the application also wants to see ^S and ^Q characters.

If you only have the V7-style interface, you tend to get the equivalent of
"stty ixon" by default.  If the system only supports the V7 interface, there's
no equivalent of "stty -ixany", so you may lose; if the system supports the BSD
interface, the equivalent of "stty -ixany" is "stty decctlq".

However, even on systems that support both the equivalent of "ixon" and
"-ixany", there may be an additional source of problems.  UNIX tends to protect
critical regions in device drivers and the like by raising the interrupt
priority; some measurements somebody once did indicated that the system on
which the measurements were done (essentially a VAX-11/780 running 4.2BSD)
spendt a fair bit of time with the interrupt priority raised to a level above
the level at which the serial port hardware interrupted.

If it spent enough time at that level, and if the serial port was run at a
high-enough baud rate, it is conceivable that the driver might not see the
interrupt indicating that the ^S came in, and thus might not see the ^S itself,
in time to stop output before the VT100's buffer overran.