Stupid MORE breaks on a rubout key when it should not

[chris at umcp-cs.UUCP]

Actually, the entire issue of breaks, framing errors, and interrupt
characters is thorougly mishandled by the Berkeley newtty driver.
The device drivers carefully convert framing errors to the appropriate
character from tp->t_chr (I don't know what they've called it in
4.2).  It should just pass the break as a special magic code, on
up into the higher level protocols.  There should be flags for
ignoring BREAK/FEs, and for generating interrupts regardless of
the interrupt character (or lack thereof, even in RAW mode) when
a BREAK/FE is detected.  (They look the same to most hardware.)

Berkeley should throw the whole thing out and write a new one that's
basically compatible with the System 5 setup, with the addition (of
course) of those ever-so-fun job control characters.

In the meantime, you have two options:  suffer with the noise, or
turn off your interrupt completely (``stty intr u'') -- this will
make all the device drivers ignore BREAK/FEs.

Chris
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris.umcp-cs at CSNet-Relay