Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards,net.bugs Subject: Re: Berkeley terminal driver user interface Message-ID: <1862@rlgvax.UUCP> Date: Sun, 15-Apr-84 22:33:52 EST Article-I.D.: rlgvax.1862 Posted: Sun Apr 15 22:33:52 1984 Date-Received: Tue, 17-Apr-84 08:05:27 EST References: <249@basser.SUN>, <449@wjh12.UUCP> <267@basser.SUN> Organization: CCI Office Systems Group, Reston, VA Lines: 50 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 ^ 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