Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!linus!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: UNIX Futures Message-ID: <3492@sun.uucp> Date: Sat, 12-Apr-86 04:03:28 EST Article-I.D.: sun.3492 Posted: Sat Apr 12 04:03:28 1986 Date-Received: Mon, 14-Apr-86 00:44:27 EST References: <67@cstvax.UUCP> <2864@amdahl.UUCP> <137@myab.UUCP> <6534@utzoo.UUCP> <1524@wucs.UUCP> <2417@teddy.UUCP> <1413@ism780c.UUCP> Organization: Sun Microsystems, Inc. Lines: 72 > Shell layers is not an attempt to imitate job control! From UNIX(TM) System V - System Release Description 2.0 - DEC(TM) Processors, April 1984, 307-006, Issue 1: 3. DETAILED FEATURE DESCRIPTIONS Job Control Job control gives users more control over their processes. It allows users to interact with different invocations of the shell, which can be conceptualized as shell "layers", only one of which receives input from the user's terminal at a time. ... The "shl" (shell layers) program is the user interface to the job control facility. ... This feature provides capabilities similar to BSD job control, but is a new implementation. ... For something which isn't an attempt to imitate job control, its description certainly uses the phrase enough times... > Shell layers is an attempt to solve the problem of multiplexing input > to several processes. Job control seems to be a kludge attempting to solve > multiple problems ( process control, input multiplexing, and output > multiplexing ) all at once. Shell layers, as you point out later, permits you to force all processes which attempt to do output when they're not the current layer to block. This sure sounds like an attempt to solve the input and output multiplexing problems all at once... > > Under Shell Layers, a ^Z (or equivalent keystroke) passes the > > terminal input to a different program, but the program that was > > intercepted is not told, and is NOT EVEN STOPPED (output will > > continue). > > Shell layers may be set up so that any process that attempts to do IO > will block. Output in this case will not continue. Yes, but what if the program isn't attempting to do output? What if, say, it's doing graphs on a VT100(TM) equipped with a board which provides Tektronix(TM) 4014 emulation, and has put the terminal in question in 4014 mode? How is the program running in that layer to know that it's layer is no longer the current layer, and that it should restore the terminal to normal mode? Then, when it becomes the current layer again, how is it to know that it's to put the terminal back into 4014 mode? Neither job control nor shell layers provides a perfect solution to the output multiplexing problem. Job control, at least, gives you hooks to put Band-Aids(TM) over some of the more obvious scars. If somebody tried to sell me a job control mechanism which forced me to clear the screen every time I suspended a screen editor, and forced me to type the "repaint the screen" key every time I restarted the screen editor, I'd show them to the door. I would find it unusable. (If shell layers does not require you to do this, somebody could do us all a great favor by explaining how.) To a large degree, this is a debate over matters of personal taste. People used to job control may argue in favor of it. People used to shell layers may argue in favor of it. I've got a window system, so most of the time I don't need either one. I occasionally move a job into the background retroactively. This is a convenience which I *could* live without. I *won't* do so, however, merely because somebody claims that job control is in bad taste - and that's what a lot of the anti-job-control claims amount to. (As for the question of "modifying lots of programs", somebody recently pointed out that many programs have *already* been modified in similar ways, for similar purposes - to support shell escapes.) -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)