UNIX Futures

[Guy Harris]

> 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 at sun.arpa	(yes, really)