kendall@wjh12.UUCP (Sam Kendall) (04/12/84)
Several people have condemned the Berkeley terminal driver, saying that
it is large and complicated. A couple have grudgingly admitted their
liking for the terminal interface (but, as Mark Horton says, not for the
ioctl interface).
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. In this case the program is the
terminal driver and the outside is the terminal interface. The terminal
interface may be the best possible given intra-line backspacing only,
and very simple from the human point of view; the complexity of the
implementation is no worry of mine.
On the other hand, I refuse to defend the ioctl interface. And I
agree with the more general criticisms of BSD; but I think the terminal
interface of the terminal driver is a notable exception.
Sam Kendall {allegra,ihnp4,ima,amd70}!wjh12!kendall
Delft Consulting Corp. decvax!genrad!wjh12!kendallboyd@basser.SUN (Boyd Roberts) (04/13/84)
> 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). What do you do when your program dies on a SIGTINT or somebody you fork hits you with a SIGTTIN or SIGTTOU? But Berkeley told you it was ok, so there's no worries. Boyd Roberts ...!decvax!mulga!boyd:basser
guy@rlgvax.UUCP (Guy Harris) (04/16/84)
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
mark@cbosgd.UUCP (Mark Horton) (04/17/84)
>>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
kendall@wjh12.UUCP (Sam Kendall) (04/17/84)
> I think more praise is due the user interface. It is ... > simple outside .... --me > 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? > > But Berkeley told you it was ok, so there's no worries. --Boyd Roberts That last is unjustified, I think; but the rest of your criticism makes some sense. My answers are that (1) I was talking about the terminal user's interface, not the program interface, and perhaps I did not make that clear; and (2) I use the Bourne shell, so I forgot about job control, which is not as beautiful as the rest, to put it mildly. Sam Kendall {allegra,ihnp4,ima,amd70}!wjh12!kendall Delft Consulting Corp. decvax!genrad!wjh12!kendall
henry@utzoo.UUCP (Henry Spencer) (04/17/84)
Guy Harris contends, in part:
.............................. 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"...
Wrong! The alternative is a proper window system, which eliminates the
requirement for *either* kludgey special signals *or* explicit repaint
requests. The only thing wrong with AT&T's approach is that they left
it half-finished. Sure, half a window system is better than none, but...
No, Virginia, you do ***NOT*** need a Blit to do windowing right. It
sure does make it easier, and there are a lot of other reasons why you
might want a Blit, but there is no law of nature prohibiting a civilized
window system for ordinary terminals.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryfair@dual.UUCP (Erik E. Fair) (04/29/84)
> From: boyd@basser.SUN (Boyd Roberts) > Subject: Re: Berkeley terminal driver user interface > Date: Fri, 13-Apr-84 10:04:56 PST > Organization: Dept of C.S., University of Sydney > > > 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). > > What do you do when your program dies on a SIGTINT or somebody > you fork hits you with a SIGTTIN or SIGTTOU? > > But Berkeley told you it was ok, so there's no worries. > > > Boyd Roberts ...!decvax!mulga!boyd:basser YOU MISSED THE POINT! Let's forget the internal implementation for a moment, which we all seem to agree is rather unfortunate. The point the gentleman was trying to make is that the Berkeley tty driver (job control most certainly NOT included) is a pleasure to use. There is no ambiguity as to what exactly you typed at any time. From the user's point of view, the Berkeley tty driver is far superior to the Bell tty driver, v7 OR System III/V. This I assert, as a USER. Job control is a separate issue, for which the Berkeley tty driver was modified to provide another set of signals bound to user settable characters. Again, as a USER, the job control stuff is wonderful to use. It allows me the flexibility to change my mind after I have started something. The number of times under non-job control systems that I have started a program running, and then wished I had shoved it in the background to begin with is beyond counting. The `tostop' stuff solves a long standing problem with the v7/sIII/sV tty driver, namely, when there are two programs contending for tty input, which one do you give the next character/line to? Prior to Berkeley, it was whoever was run by the scheduler next. With Berkeley's tty driver and job control, you stop the process group that is in the background. Now, let me change hats here... (I know I have my wizard's cap in here somewhere... Ah, here it is) As a UNIX systems programmer, I agree with what you have said. The internals of the Berkeley tty driver are horribly convoluted, and the job control stuff complicates matters beyond reason. BUT! Unlike Bell, the Berkeley CSRG took the time and trouble to modify the affected programs, so that you didn't have to, when you got 4.1BSD. This is considerably more than I can say for Bell, who, when they dropped System III on us with a completely new tty driver, still had stty/gtty calls in a significant number of important programs (e.g. getty). I suggest two rules for making Kernel mods (as distinguished from additions): 1) If you're going to break something, break it ALL the way. Don't leave vestiges of the old world lying around for people to trip on. 2) Be sure to go back and fix all the affected software. If you don't have the guts to do so, the original change wasn't important enough to you and you shouldn't have made it. Now, just what have you done for UNIX lately, Mr. Roberts? I have respect for Rob Pike when he complains about UNIX, because in his realm, he did something about it. He didn't like the UNIX tty driver or Berkeley job control. So he (and presumably others) designed the BLIT, which we all know (well sort of) as the TTY 5620, as an answer to that. It so happens that I disagree with some of what Mr. Pike has to say, but the TTY 5620 stands as his counter proposal as `the right way to do things'. Without that kind of counter proposal, your criticism becomes no more than informed whining. Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA dual!fair@Berkeley.ARPA {ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair Dual Systems Corporation, Berkeley, California