henry@utzoo.uucp (Henry Spencer) (06/08/89)
In article <8167@boring.cwi.nl> roberto@cwi.nl (Rob ten Kroode) writes: >I asked Andy some advise, and he told me that he didn't like the idea of >job control in Minix... Job control is a stupid, poorly-thought-out, ass-backwards excuse for a window system. It's mostly just a way of interacting with multiple processes. Window systems do it much better, since they provide central control of output as well as input, and if done well, it is transparent to user programs (instead of requiring ugly hacks in each and every one). No, you do not need a bitmapped display to do a window system. One of my bigger regrets is that after Ian Darwin and I succeeded in getting job control excluded from the /usr/group Unix interface standard, I got busy with other things and didn't keep a sharp eye on POSIX (which started from the /usr/group standard)... and job control, slimy tentacles and all, slithered back in when I wasn't watching. If anyone is interested, I think I still have the scathing commentary on job control that Ian and I did at the time. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
tim@crackle.amd.com (Tim Olson) (06/08/89)
In article <1989Jun7.224933.700@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | In article <8167@boring.cwi.nl> roberto@cwi.nl (Rob ten Kroode) writes: | >I asked Andy some advise, and he told me that he didn't like the idea of | >job control in Minix... | | Job control is a stupid, poorly-thought-out, ass-backwards excuse for a | window system. It's mostly just a way of interacting with multiple | processes. Window systems do it much better, since they provide central | control of output as well as input, and if done well, it is transparent | to user programs (instead of requiring ugly hacks in each and every one). In a related question, has anyone else worked on "virtual terminal" support for the console? By this, I mean the ability to have multiple simultaneous sessions, and the ability to flip between them with a "hot-key", like F3. I have seen this in other systems, and thought it would be an interesting thing to add. I'm not quite finished with it, but it appears to drop in very easily to tty.c, at least on the PC version of MINIX. -- Tim Olson Advanced Micro Devices (tim@amd.com)
jds@mimsy.UUCP (James da Silva) (06/08/89)
In article <1989Jun7.224933.700@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Job control is a stupid, poorly-thought-out, ass-backwards excuse for a >window system. It's mostly just a way of interacting with multiple >processes. Window systems do it much better, since they provide central >control of output as well as input, and if done well, it is transparent >to user programs (instead of requiring ugly hacks in each and every one). Interesting. I often find myself using job control to stop a process without killing it. Or doing simple things like putting ftp, compress, or rm into the background when they are taking longer than expected. How does your alternative handle things like these? Do I have to explicitly run each command in a separate window? >No, you do not need a bitmapped display to do a window system. Granted. Do you need a fast terminal? How do I do windows at 2400 baud without spending all my time redrawing the screen, or dividing its 25x80 chars into tiny `windows'? >If anyone is interested, I think I still have the scathing commentary on >job control that Ian and I did at the time. I'm interested. I think you should post to comp.os.minix; Minix is about learning OS design tradeoffs, after all. Jaime ........................................................................... : domain: jds@mimsy.umd.edu James da Silva : path: uunet!mimsy!jds
henry@utzoo.uucp (Henry Spencer) (06/09/89)
In article <1989Jun7.224933.700@utzoo.uucp> I wrote: >If anyone is interested, I think I still have the scathing commentary on >job control that Ian and I did at the time. I'm already getting a steady stream of requests for this, so here it is. If I were formally submitting it today I'd probably make some small changes, but I don't have time for that now (so bear in mind that it's old). Also, I have not consulted Ian about this and cannot say whether his views have changed or not. ---------- .TL Comments on Terminal I/O, Specifically `Job Control' .AU Henry Spencer .AI University of Toronto utzoo!henry .AU Ian Darwin .AI University of Toronto .SH `Job Control', What It's Really About .PP There is no longer any argument that it is desirable to permit orderly user interaction with multiple processes. Unfortunately, a whole generation of Unix users has had their view of this concept warped by the dreadful way it was implemented by Berkeley. And AT&T, in its recent attempt to address the problem, has taken the easy way out instead of doing it right. .PP The basic concept involved here is multiplexing, not `job control' or process suspension. The ideal is something like the environment on the Bell Labs Blit, where multiple processes run simultaneously in multiple windows, and the user can switch his attention and his interaction from one to another at will. There is a popular misconception that doing this \fIrequires\fR a Blit or a similar highly-intelligent terminal; this is simply not true. .PP Window-based multiplexed interaction is harder to do when the terminal is dumb, but even the Blit is not actually writing things into several windows \fIsimultaneously\fR: it just looks that way because of the high-speed multiplexing involved. There is no intrinsic reason why this multiplexing cannot be done at the other end of the communications line when the terminal is incapable of doing it. .PP The multiplexing can be done in the kernel (albeit at considerable cost in added kernel complexity) or in a user process (given suitable interprocess communication). In either case, the fundamental structure is quite simple: a central `manager' coordinates terminal i/o to and from `client' processes, each of which has total control of its own "virtual terminal". The manager's job is simulating multiple virtual terminals on a single real terminal, by routing input to the appropriate process and placing output in the appropriate area of the screen. .PP The basic characteristics of such a multiplexing system are that each process has what looks (to it) like a private terminal, and that all i/o to and from the user is centrally supervised. This is precisely analogous to file i/o under Unix: simultaneous independent activity by multiple processes, coordinated by a central manager which multiplexes physical resources so as to prevent interference. The benefits are similar: individual processes neither know nor care about the multiplexing, and useful high-level abstractions can be implemented in one central place. .SH Job Control and Layers: Half-Baked Approaches .PP The existing schemes, Berkeley `job control' and AT&T `layers', unfortunately are clumsy and incomplete attempts at implementing multiplexed interaction. Neither one makes any provision for simultaneous on-screen activities by more than one process, except for the `cop-out' of permitting multiple processes to intermix their output at random. But there are deeper problems. .PP Both schemes require that \fIevery\fR \fIprogram\fR which is going to participate in multiplexed interaction must contain code to allow for this possibility! User programs must be prepared to redraw the screen on request, with the requests coming from the kernel in the Berkeley scheme and from the user in the System V.2 scheme. This is an abomination. .PP Not only does this demand specialized code in every user program, but it entirely denies multiplexed interaction to the bulk of Unix programs. The concept of `redraw the screen' is meaningful only for interactive programs with full-screen interfaces. The result of, say, an \fIegrep\fR, once replaced on-screen by (say) the editing buffer of a \fIvi\fR, is gone for good. Since \fIegrep\fR is not an interactive program, it is no longer around to be asked to redraw its output. .PP The heart of the problem is that neither job control nor layers implements the crucial half of a window system: centralized management of screen updates. It has long been accepted that multiple processes cannot safely do updates to disks without centralized management and consistency control. The same obviously applies to terminal i/o: orderly simultaneous interaction with multiple processes requires centralized supervision of the interaction. The existing schemes supervise input but not output. .PP It is obvious \fIwhy\fR this deficiency exists: supervising output is the hard part. The idea of switching input from one program to another is reasonably straightforward. Differences in input handling, such as `cooked' vs. `raw' modes, are relatively minor problems, since the user can be conversing with at most one process at a time. But a CRT terminal permits output from multiple processes to be displayed simultaneously, and coordinating screen updates isn't trivial. Furthermore, there is no agreement on the precise user interface that should be presented for output \(em consider, for example, the religious debates over overlapping vs. non-overlapping windows \(em and this discourages attempts to provide a single and relatively inflexible central solution. The immense variation in CRT-terminal control sequences puts the icing on the cake. .PP Nevertheless, these problems \fIcan\fR be solved. There are at least three, and probably several more, complete window systems in experimental use. Some of them have performance problems, and most of them are outside the kernel and hence have interprocess-communication problems, but they do work. .SH Standardizing Multiplexed Interaction: A Recommendation .PP As mentioned above, several experimental window systems already exist. (This is quite apart from the `real' window systems on bitmapped workstations, which are also relevant.) Experience with these and other implementations of the same concept will yield a wealth of knowledge on how best to handle this function. It is important that this experimentation, and the adoption of the results that come out of it, not be stifled by further `official endorsement' of incomplete and badly-designed existing schemes. .PP The best approach for /usr/group to take on this matter would be to reserve some characters, and some flag bits, for implementations of multiplexed user interfaces, but not to specify any such interface at this time. Such an attempt to specify the interface would be premature, especially when the two approaches under consideration are already known to be grossly-incomplete botches. .PP \fINeither Berkeley `job control' nor AT&T `layers' is an adequate implementation of a multiplexed user interface. Neither one should be cast in concrete as a standard at this time.\fR .SH A Retraction .PP Our previous recommendation was that, if multiplexed interaction \fImust\fR be standardized, AT&T `layers' would be a better place to start. The layers system, unlike Berkeley job control, does do input multiplexing more-or-less correctly, and hence is essentially upward-compatible with true window systems. It has several desirable characteristics: independent tty state for each layer, suspension/resumption invisible to the processes, a central manager process which is \fInot\fR imbedded in a shell, and an implementation that does not have ramifications everywhere. .PP Nevertheless, as discussed above, it doesn't do the hard part: output multiplexing. It also has some annoying implementation limits, which, although they wouldn't necessarily have to propagate into a standard, might well propagate into most early implementations. Its major problem is that it's not clear how to extend it to centralized output management without imbedding said management inside the kernel. .PP We therefore retract our recommendation for standardizing layers as a second choice. The proper course is to standardize nothing, at least until we understand the user-interface issues and the implementation problems better. .SH Specifics .PP A decision not to standardize a multiplexed-interaction scheme notwithstanding, there are a few useful minor things that can be standardized. The \fItermio\fR structure probably should have a reserved character or two (or room for same) and a few reserved bits (or room for same) to permit kernel-based implementations of multiplexing. .PP In particular, almost any multiplexing scheme using ordinary ASCII terminals will need a special character to attract the attention of the multiplexing software. Without this, it's very difficult to do things like moving between windows. Reserving space for such a character might be useful; recommending a default choice for the character would be very valuable, as it would forestall unnecessary differences between implementations. Control-Z would be plausible. .PP Implementing supervision of multiplexed interaction in user processes is difficult in many existing Unix implementations, minimal implementations of the existing /usr/group standard among them. The basic problem is that normal user processes are definitely aware that their output is going to a terminal, the device-independence of Unix i/o notwithstanding. Screen-oriented programs doing \fIioctl\fRs are the biggest problem. A less obvious glitch is that \fIstdio\fR adjusts its buffering strategy depending on whether output is to a terminal or not; this is a major nuisance with some existing window systems. Something like the `pseudo-tty' concept would be very useful: an entity which looks like a terminal from one side, but whose behavior is under user-process control from the other side. Some existing systems do implement such things, but the lack of standardization largely prevents use of them in portable programs. .SH Suspending Processes: A Non-Issue .PP Several people have objected to AT&T layers, and similar approaches, on the grounds that `...but 4BSD lets me suspend misbehaving processes...'. This is silly; a process-suspension facility can be very simple if it isn't required to double as a multiplexing system. .PP If it is thought desirable to standardize process suspension, we would suggest the following. Some magic character (control-Y?), when typed as input to a tty/window, suspends all processes attached to that tty/window. The suspension can be, and should be, utterly invisible to the processes involved. This avoids the sticky problem of how to notify the processes without doing incompatible things to the \fIsignal\fR mechanism. The suspension probably should have a permission requirement analogous to that of signals: if the effective userids of the user and the process don't match, the suspension doesn't happen. This is necessary to prevent major security breaches like suspending \fIpasswd\fR(1) in the middle of an update to the password file. .PP Note that this suspension facility isn't very useful in the absence of multiplexed interaction \(em you can't \fIdo\fR anything to a suspended process without access to another (real or virtual) terminal \(em but the two concepts are nevertheless quite independent. There is no need to confuse them. .SH Miscellaneous Comments .PP Departing from multiplexed interaction, we'd like to raise again a couple of minor issues mentioned in the previous paper... .PP An ignored hangup signal should not only cause reads to return end-of-file, it should also cause writes to be no-ops. Hangup should, in general, disconnect lingering processes from the terminal completely, so they don't hang around to bedevil the next user. .PP One extremely useful feature that is missing is terminal pagination. To quote Rob Pike: ``terminals should not scroll [without the user's permission]''. Many people think this a useless frill, but they almost invariably are people who have never tried it. Most people who try it seriously, love it. Even the simplest and crudest implementations (such as the one on the system this document is being written on) are major improvements on a terminal interface that lacks this feature. This is not a new and unknown idea: it has been conceived and implemented independently at least three times, has been in use for years, and is generally perceived by its users as a big win. ---------- -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
oz@yunexus.UUCP (Ozan Yigit) (06/09/89)
Part of a summary paragraph of some thoughts from DMR regarding Job Control (net.unix.wizards: 12 apr 86): [I do not have the whole article on line anymore] > My impression is that BSD job control is something that was > put in by expedient means in order to achieve a certain effect, and the > effect is excellent, within the serious limitations of the mechanism. > SV job control was done with a cleaner conceptual foundation, but with > a less lucid view of what it is for, and less effort devoted to making > it useful. Indeed, I suspect it is not much used. oz -- SomeOS4.n: Brooks was right all Usenet: oz@nexus.yorku.ca along, but it shouldn't take so ......!uunet!utai!yunexus!oz large a pie in a face to figure Bitnet: oz@[yulibra|yuyetti] it out.. anon. Phonet: +1 416 736-5257x3976
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (06/09/89)
Henry Spencer's article contains some explicit and implicit assumptions
that I will counter briefly:
1. Job control versus multiple windows is a false dichotomy.
2. Each and every program does not need special code to deal with
job control. Only programs that change terminal settings,
and privileged programs that should not be interrupted by
unprivileged users, need such code.
3. Multiple windows are useless at 1200 bps.
4. Multiple windows are useless on a hardcopy terminal.
The best solution is to allow multiple windows, and job control within
each. This lets the user decide which to use: multiple windows only,
or job control only, or a combination of both.
--
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
Career change search is on -- ask me for my resumejca@pnet01.cts.com (John C. Archambeau) (06/09/89)
I don't understand your prejudice against job control. If you mean job
control via the csh and BSD UNIX then arguing that it isn't any good is like a
two year old arguing over what his favorite flavor of ice cream is. Whether
or not you want job control and the csh in Minix is your business, but there
are some of us who do. I hate SysV Unix because of its lack of job control,
there are times when I want to do a ^Z and suspend a job just to find out what
the (*bleep*) is going on with the rest of the system, then I go put it in the
background or do something else. Job control is a nice feature of the user
controlling his/her processes and since enough of us here are fond of BSD
Unix, it's obviously a well used feature of the csh.
/*--------------------------------------------------------------------------*
* That's not an operating system, this is an operating system!
*--------------------------------------------------------------------------*
* UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
* APRA: crash!pnet01!jca@nosc.mil
* INET: jca@pnet01.cts.com
*--------------------------------------------------------------------------*/
#include <disclaimer.h>poage@sunny.ucdavis.edu (Tom Poage) (06/10/89)
I get the impression that a number of people dislike csh, but have a hard time getting along without job control. Anyone care to take a crack at writing an AT&T-free ksh? :-) Tom.
henry@utzoo.uucp (Henry Spencer) (06/10/89)
In article <17958@mimsy.UUCP> jds@mimsy.umd.edu (James da Silva) writes: >Interesting. I often find myself using job control to stop a process >without killing it. Or doing simple things like putting ftp, >compress, or rm into the background when they are taking longer than >expected. How does your alternative handle things like these? Do I >have to explicitly run each command in a separate window? No, just shift to a fresh window when -- and only when -- the one you're running in is taking too long to finish. >Granted. Do you need a fast terminal? How do I do windows at 2400 >baud without spending all my time redrawing the screen, or dividing >its 25x80 chars into tiny `windows'? At low speeds, typically the best way to organize windows is to make them the size of the screen and have only one showing at a time. There is no need for screen redrawing to involve any more characters than sending stuff to the screen in the ordinary way, unless the window manager is stupid. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (06/10/89)
In article <7652@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >1. Job control versus multiple windows is a false dichotomy. Please elaborate; looks like a real one to me. >2. Each and every program does not need special code to deal with > job control. Only programs that change terminal settings, > and privileged programs that should not be interrupted by > unprivileged users, need such code. And any program for which there is any likelihood that its output might have to be redrawn. That is, every program. >3. Multiple windows are useless at 1200 bps. Then don't put more than one on the screen at a time. The others are still accessible if needed. >4. Multiple windows are useless on a hardcopy terminal. True. How many people work on hardcopy terminals? >The best solution is to allow multiple windows, and job control within >each... Why provide two ways of doing the same thing? See Ken Thompson in the original Unix papers on the virtues of doing things only one way. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
chasm@killer.DALLAS.TX.US (Charles Marslett) (06/10/89)
In article <1989Jun10.063315.26085@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > >the best solution is to allow multiple windows, and job control within > >each... > > Why provide two ways of doing the same thing? See Ken Thompson in the > original Unix papers on the virtues of doing things only one way. What this all boils down to, I think, is that a window manager has to do all the things job control does, and some even allow programs written with no knowledge of the window manager's operation to run. Job control on the other hand, is a subset of the window manager's functionality, so it must be either replaced (as I understand the normal scheme of things handles it) or the duplicate functions trip all over each other when you add a windowing scheme. The primary issue I would like to raise is how much of a performance hit do you get by adding the window manager to the screen output/keyboard input path over having the simpler job control scheme. I do not mean X11 or whatever, just an OS/2 style monitor to map I/O to various "logical windows". Has anyone ever done this? > -- > You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology > but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu Charles Marslett chasm@killer.dallas.tx.us
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (06/11/89)
Countering Henry Spencer's response to my article: Job control versus multiple windows is a false dichotomy because one does not exclude the other. >>2. Each and every program does not need special code to deal with >> job control. Only programs that change terminal settings, >> and privileged programs that should not be interrupted by >> unprivileged users, need such code. > >And any program for which there is any likelihood that its output might >have to be redrawn. That is, every program. No. If a program produces strictly sequential output, you only need to redraw it if it has scrolled off your screen or been overwritten by the output from some other screen-oriented program. But this is not caused by job control, so job control should not be blamed for it. If you want all output from a program to be always accessible, you need a virtual screen much bigger than your physical screen. Multiple windows are neither necessary nor sufficient to give you that. >>3. Multiple windows are useless at 1200 bps. > >Then don't put more than one on the screen at a time. The others are still >accessible if needed. It takes too long to redraw the screen at 1200 bps. Switching between windows is painful at less then 9600 bps, and even at 9600 bps it is an inconvenience. >>4. Multiple windows are useless on a hardcopy terminal. > >True. How many people work on hardcopy terminals? I don't know. I occasionally do when I need a record of what I did. How do you make a log of everything you did in a terminal session in order while still using multiple windows? Re job control + windows: >Why provide two ways of doing the same thing? One of them doesn't work well under certain circumstances, such as 1200 bps, and the other doesn't let you flexibly handle concurrent jobs that produce output to the screen. If you value both situations you need both job control and multiple windows. For jobs that expect no input from the terminal, I find it most convenient to redirect all output to a log file. This effectively gives me a much bigger window into the output than any conventional windowing scheme would. And at any time I can do "tail -f logfile" and see the output in real time, and I can even suspend *this* job (running tail) and resume it later if I wish. If we all had high-speed links (at least 19.2 kbps), and big terminals (perhaps 100 characters by 100 lines), multiple windows might be the perfect replacement for job control. Perhaps in 1995 or so Henry Spencer's claims will be indisputable. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi Career change search is on -- ask me for my resume
ncoverby@ndsuvax.UUCP (Glen Overby) (06/12/89)
In article <393@sunny.ucdavis.edu> poage@sunny.ucdavis.edu (Tom Poage) writes: >Anyone care to take a crack at writing an AT&T-free ksh? :-) Tom. Somebody already has. You can FTP it from urth.cc.buffalo.edu. We've tried compiling it on a 4.3BSD VAX, and it doesn't. -- Glen Overby <ncoverby@plains.nodak.edu> uunet!ndsuvax!ncoverby (UUCP) ncoverby@ndsuvax (Bitnet)
chet@kiwi.CWRU.EDU (Chet Ramey) (06/12/89)
In article <393@sunny.ucdavis.edu> poage@sunny.ucdavis.edu (Tom Poage) writes: >I get the impression that a number of people dislike csh, but >have a hard time getting along without job control. I'm one. I use job control and windows all the time. >Anyone care to take a crack at writing an AT&T-free ksh? :-) Tom. It's being done, and in more than one place. Brian Fox, with a little help from the masses (again, I'm one :-), has just released version 0.99 of bash, the Bourne-Again SHell. This is the GNU project's Bourne+ Shell. It has the job control, command-line editing, tilde expansion, etc. that ksh provides in addition to bourne shell compatibility. It's really a good shell, already an implementation of the current POSIX shell specification (part of the output of 1003.2), and I expect it to pick up more ksh features as time goes on. The first I'm expecting is expression evaluation (the (( )) stuff). Eric Geisen, at the University of Waterloo, is working on a PD ksh, with full compatibility as its goal. I picked up an old version from Toronto (don't even try -- they restricted FTP access to it soon after it was announced as available). This version had emacs-style editing, job control (both picked up from the BRL s5r2 shell), nearly full s5r2 sh compatibility, and other goodies. I'm sure it's being worked on as well, but no version of it is currently available from either Waterloo or Toronto, and Eric has not been very good about answering mail about availability. Chet Ramey Network Services Group, CWRU chet@cwjcc.INS.CWRU.Edu "Unix System V: From now on, consider it sub-standard" Chet Ramey Network Services Group, CWRU chet@{cwjcc,pirate}.INS.CWRU.Edu "The flagon with the dragon has the potion with the poison; the vessel with the pestle holds the brew that is true!"
charles@hpcvca.CV.HP.COM (Charles Brown) (06/13/89)
>>> the best solution is to allow multiple windows, and job control within >>> each... >> Why provide two ways of doing the same thing? See Ken Thompson in the >> original Unix papers on the virtues of doing things only one way. >> Henry Spencer at U of Toronto Zoology >What this all boils down to, I think, is that a window manager has to do >all the things job control does, and some even allow programs written with >no knowledge of the window manager's operation to run. Job control on the >other hand, is a subset of the window manager's functionality, so it must >be either replaced (as I understand the normal scheme of things handles it) >or the duplicate functions trip all over each other when you add a windowing >scheme. > Charles Marslett I have not seen a window manager which provides *suspend*. I occasionally have large simulations which spend several days running, during which time they spend lots of time swapping portions to disk. The task already is in the background. I want to be able to suspend it so it does not slow me down in my daytime tasks (by always swapping my foreground tasks to disk be cause I stopped typing for a second). Then each evening before I leave I can restart the simulation and let it swap away all it wants. Windows do NOT replace job control. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer. "The guy sure looks like plant food to me." Little Shop of Horrors
allbery@ncoast.ORG (Brandon S. Allbery) (06/13/89)
As quoted from <17958@mimsy.UUCP> by jds@mimsy.UUCP (James da Silva): +--------------- | In article <1989Jun7.224933.700@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | >Job control is a stupid, poorly-thought-out, ass-backwards excuse for a | >window system. | | Interesting. I often find myself using job control to stop a process | without killing it. Or doing simple things like putting ftp, | compress, or rm into the background when they are taking longer than | expected. How does your alternative handle things like these? Do I | have to explicitly run each command in a separate window? +--------------- I use JSB Multiview at work; if I need to kill a process or want to switch something into the "background", I just pop up the Multiview menu and select or open another window to work in. -> If you can't manipulate windows dynamically, it's a p*ss-poor window system. +--------------- | >No, you do not need a bitmapped display to do a window system. | | Granted. Do you need a fast terminal? How do I do windows at 2400 | baud without spending all my time redrawing the screen, or dividing | its 25x80 chars into tiny `windows'? +--------------- "Window system" does not necessarily imply multiple on-screen windows. I use Multiview with 80x25 (status line on our terminals is also windowed!) -- and BSD comes with a critter called "screen" which does the same thing, 80x25 "windows". With this setup, it costs little more (only pty overhead) to run windows as not -- I also use MultiView over the modem, although not often because it has a rather brain-damaged way of dealing with insert/delete multiple lines (ANSI ESC [ nnn L, et alia). +--------------- | >If anyone is interested, I think I still have the scathing commentary on | >job control that Ian and I did at the time. | | I'm interested. I think you should post to comp.os.minix; Minix is | about learning OS design tradeoffs, after all. +--------------- Seconded. Although you might cross-post to comp.unix.wizards, assuming you want to start a flame war ;-) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
mfuller@prandtl.nas.nasa.gov (Mike J. Fuller) (06/16/89)
In article <5870009@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: [Lots of stuff deleted...] >Windows do NOT replace job control. Ditto. At the moment, I'm working on sun 4/260 and I can start up lots of windows plenty quick, but I still use job control within my windows frequently. /---------------------------------------------------------------------------\ | Mike J. Fuller |Internet: mfuller@prandtl.nas.nasa.gov|You'd be paranoid, | |----------------| mikef@vax1.cc.uakron.edu |too, if everyone | |/\/\/\/\/\/\/\/\|Bitnet: r3mjf1@akronvm |was out to get you!| \---------------------------------------------------------------------------/
mfuller@prandtl.nas.nasa.gov (Mike J. Fuller) (06/16/89)
In article <8336@killer.DALLAS.TX.US> chasm@killer.DALLAS.TX.US (Charles Marslett) writes: >In article <1989Jun10.063315.26085@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: [Lots of stuff deleted...] >The primary issue I would like to raise is how much of a performance hit do >you get by adding the window manager to the screen output/keyboard input path >over having the simpler job control scheme. I do not mean X11 or whatever, just >an OS/2 style monitor to map I/O to various "logical windows". Has anyone >ever done this? To a certain extent, yes. A long time ago, I built a program called "screen" on our suns here. I can't remember where I got it, but it does exist and work on machines with BSD support. It's README file begins: "screen" is a window manager that allows you to handle several independent screens (UNIX ttys) on a single physical terminal; each screen has its own set of processes connected to it (typically interactive shells). Incidently, I rarely use screen because _I_ have job control. :-) I only built it because there is no way to escape from and suspend a decnet login like a telnet or rlogin (sun's dni software s*cks), and that is rather frusterating when you're logged in from a 80x24 terminal. Also, on PC's, NCSA telnet provides a similar "window" system. It is rather nice and fast. /---------------------------------------------------------------------------\ | Mike J. Fuller |Internet: mfuller@prandtl.nas.nasa.gov|You'd be paranoid, | |----------------| mikef@vax1.cc.uakron.edu |too, if everyone | |/\/\/\/\/\/\/\/\|Bitnet: r3mjf1@akronvm |was out to get you!| \---------------------------------------------------------------------------/
preston@felix.UUCP (Preston Bannister) (06/17/89)
From article <1989Jun10.063047.26030@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): > In article <17958@mimsy.UUCP> jds@mimsy.umd.edu (James da Silva) writes: >>Interesting. I often find myself using job control to stop a process >>without killing it. Or doing simple things like putting ftp, >>compress, or rm into the background when they are taking longer than >>expected. How does your alternative handle things like these? Do I >>have to explicitly run each command in a separate window? > > No, just shift to a fresh window when -- and only when -- the one you're > running in is taking too long to finish. I partly disagree. Sometimes I'll shift to a fresh window and let the command run. At other times (usually when there is some state associated with the current window) it is more efficient suspend and background the (long running) command. >>Granted. Do you need a fast terminal? How do I do windows at 2400 >>baud without spending all my time redrawing the screen, or dividing >>its 25x80 chars into tiny `windows'? > > At low speeds, typically the best way to organize windows is to make them > the size of the screen and have only one showing at a time. There is no > need for screen redrawing to involve any more characters than sending > stuff to the screen in the ordinary way, unless the window manager is > stupid. The answer to this question depends on how your "windows" are implemented. When I dial into work from home, I usually run a version of UW ("Unix Windows"). UW provides multiple simulated terminals (each "terminal" screen in it's own window) with only a single serial connection to the host machine. I find that 2400 baud is _much_ more livable using UW as my local (home) machine does all repaints from it's internal representation of the "screen" in each window. --- Preston L. Bannister USENET : {hplabs,oliveb,spsd,zardoz}!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister -- Preston L. Bannister USENET : {hplabs,oliveb,spsd,zardoz}!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister
henry@utzoo.uucp (Henry Spencer) (06/20/89)
In article <7687@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >Job control versus multiple windows is a false dichotomy because one >does not exclude the other. They merely duplicate each other. >... If a program produces strictly sequential output, you only need to >redraw it if it has scrolled off your screen or been overwritten by the >output from some other screen-oriented program. But this is not caused >by job control, so job control should not be blamed for it. Job control can quite fairly be blamed for failing to solve it, however. >How do you make a log of everything you did in a terminal session in >order while still using multiple windows? How do you make such a log with ONE window if you're running screen- oriented programs, like say a modern editor, whose i/o can't be logged easily? There just ain't no graceful way. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
scottw@ico.ISC.COM (Scott Wiesner) (06/20/89)
This is all just too much. Job control with or without a windowing system is a useful tool. Just yesterday, I was doing a large build on my system, when I decided I wanted to run a timing test on something else. If I had had job control, this would have been a simple matter of doing a ^Z, running my test, and continuing the build. Instead, I had to *kill* the build, run my test, and start a new build. It's just not the same. Call it a bug or call it a feature. I really don't care. The point is, a lot of us find it useful. If you don't, fine, but don't tell me I'm wrong for using it. Scott Wiesner
henry@utzoo.uucp (Henry Spencer) (06/21/89)
In article <15868@vail.ICO.ISC.COM> scottw@ico.ISC.COM (Scott Wiesner) writes: >This is all just too much. Job control with or without a windowing >system is a useful tool. Just yesterday, I was doing a large build >on my system, when I decided I wanted to run a timing test on something >else. If I had had job control, this would have been a simple matter >of doing a ^Z, running my test, and continuing the build... Nobody, including me -- please *read* my postings, especially the long one -- is arguing that the ability to suspend jobs is not useful. But that is about 2% of job control. The trouble comes when you stir that together with screen updating and multiplexing, yielding a big mess. -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (06/22/89)
In article <1989Jun21.165326.1650@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Nobody, including me -- please *read* my postings, especially the long >one -- is arguing that the ability to suspend jobs is not useful. But >that is about 2% of job control. Using csh under 4.3BSD, job control as seen by the user (not the kernel implementor) is approximately 50% suspending jobs 50% resuming jobs (This is a very rough approximation. An argument could be made that one should also include about 4% checking the status of jobs, 1% posting Usenet articles about it, etc.) -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
henry@utzoo.uucp (Henry Spencer) (06/24/89)
In article <7881@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >>Nobody, including me -- please *read* my postings, especially the long >>one -- is arguing that the ability to suspend jobs is not useful. But >>that is about 2% of job control. > >Using csh under 4.3BSD, job control as seen by the user (not the kernel >implementor) is approximately ... The kernel implementor, and the systems programmer in general, is what I was talking about. -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu