any harm in allowing only ctrl-Q to restart output?

[Rob Warnock]

+---------------
| I'd like to change UNIX to require ctrl-Q (actually t_startc)
| to restart output. With our terminals, it can only improve things -
| ... Is this likely to cause any problems anywhere else?
| 
| We're running v7 on a Perkin-Elmer 3220, by the way. The change is
| trivial - commenting out two lines in /usr/sys/dev/tty.c.
| As an alternative, I'm thinking of creating a new ioctl setting
| (TIOCQSTART?) which controls this behaviour, so it's user-settable.
| Any comments on that idea?
| 
| Dave Sherman | The Law Society of Upper Canada | Toronto
+---------------

The 4.1bsd (and 4.2bsd too?) has a tty mode set by "stty decctlq" which,
as it says in "stty(1)", means:

    decctlq	After output is suspended (normally by ^S), only a start
		character (normally ^Q) will restart it. This is compatible
		with DEC's vendor supplied systems.

Likewise:

   -decctlq	Atfer output is suspended, any character typed will restart
		it; the start character will restart output without providing
		any input. (This is the default.)

At Fortune Systems (which used a v.7-based kernel), the "decctlq" feature
was needed (and added to the kernel, along with most of the 4.1 tty stuff)
to solve problems similar to yours with overrunning terminals which were
taking a long time to perform complex area fills. The user had no way of
knowing the output was turned off, but was just holding down a cursor
motion key (on auto-repeat), causing the driver to start output too soon
after the terminal had shut it off! (Also, the cursor was a 3-char sequence,
and the driver was eating one or the other of the chars when restarting
output.)

So, yes. It is a needed feature. The only thing you want to make sure of
is that even if output is stopped, the interrupt and quit functions must
turn it back on (when the terminal is not in "raw" mode). Otherwise, you
can confuse and frustrate the user, who hit XOFF to stop the action, and now
can't get his/her shell back! (Breaking the <DEL> key... <DEL> <DEL> <DEL>...)
An XON gets a string of prompts which have been stacked up, leading to
more confusion. (Certain versions had that problem, and it hurt.)

I suspect that if you merely "comment out the two lines" you will create
the bug. Be careful. (Get 4.1 sources, if your license permits.)

Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404