Berkeley terminal driver user interface

[Guy Harris]

We've been over this before, but...

>>   I think more praise is due the user interface.  It is a
>>   good thing for a computer program to be simple outside
>>   (specification) and simple inside (implementation); but
>>   a computer is used best when a program is simple outside
>>   but complex inside--the user sees the simplicity, and
>>   the computer takes care of the complexity.

>How can you say that the Berkeley terminal driver (i.e. job control) 
>provides a simple outside world?  Do you not have to fix things
>like vi, more and (of all things!!) the shell to understand
>about what the terminal driver is likely to do?  However only C-shell
>was fixed (C-shell too slow).

The USG driver's interface to character erase is considerably more complicated
than Berkeley's.  On a CRT terminal, with Berkeley's, what you see is what
you get 99% of the time, and the other 1% of the time you just hit ^R.
With USG's, what you see is what you get *unless*:

1) what you erased was a TAB
2) what you erased was a control character

and there's *no* ^R facility.

Furthermore, if you hit a control character, you'd better know it's there
because it's echoed as itself - with Berkeley's, it's echoed as ^<whatever>
so at least you know you typed it.  This is even more strongly the case for
control characters like ^D which have a special effect on the TTY driver.
Anybody else out there typed a ^D without it being echoed, not been sure whether
it really got there, and typed another one only to find that the first one
*did* get there and the second one logged you out?

>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"...

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy