Berkeley terminal driver user interface

[Mark Horton]

>>What do you do when your program dies on a SIGTINT or somebody
>>you fork hits you with a SIGTTIN or SIGTTOU?
>
>By and large, you don't do anything; the default action for those signals is
>to ignore them.  If you want or need to use them, you can; otherwise, you
>can totally ignore them.  If you were thinking about SIGSTOP or SIGTSTP,
>again, the default action is what you want in 90% of the cases - when you
>get the SIGTSTP, you are immediately put into the stopped state and
>automatically restarted when you get a SIGCONT.  In the other 10% of the
>cases, such as screen editors which have to clear the screen when suspended
>and repaint it when restarted, the alternative is something like AT&T's
>"job control" which, admittedly, doesn't have stop/start signals so you can
>claim you don't have to change your code; you just have to remember to type
>^L every time you reactivate "vi"...

While a handfull of screen oriented programs were changed to know about
SIGTSTP, that is changing.  Curses automatically handles ^Z so that the
application program need not know about it if it doesn't want to; curses
will catch the SIGTSTP, move the cursor to the bottom of the screen, restore
the terminal to "non-screen" mode, and suspend itself.  When resumed, it
restores the terminal to "screen" mode, redraws the screen, and repositions
the cursor.  (This is true of both the Ken Arnold curses and my version, but
only on 4BSD.)  If the program wants to do more, it can catch the signal and
handle it as it wishes.

This doesn't help programs that don't use curses, but lower level routines
are being developed.  (The latest curses can be used to write filters, such
as more.)  Existing programs, such as vi and more, need not be rewritten,
they already work.  Other low level programs tend to run quickly enough that
they are seldom interrupted (e.g. tset) or should not be interrupted (e.g.
sending something to the printer port.)  Non-interruptable programs have
to add one line to ignore SIGTSTP.  Would you argue that SIGINT and SIGQUIT
are bad because programs that want to run without being interrupted must
include a line to ignore them?

	Mark Horton