UNIX Futures

[nz at wucs.UUCP]

In article <6534 at utzoo.UUCP> henry at utzoo.UUCP (Henry Spencer) writes:
 > > >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its
 > > >screen.
A program can catch ^Z, by  ``signal(SIGTSTP, stop_handler)''.
Further, the program can also catch the continue -- which lets it redraw the
screen or print a message or change its state or whatever.  I have several
programs which do both.

 > > 	When this is fixed I will admit that shell layers are a
 > > workable substitute for full job control! What good does it do to stop
 > > a job if I cannot restart it transparently?
You can.

 > What good does it do to be able to stop and start jobs if every program
 > has to know about it to redraw the screen?  Also, what do you do about
 > output from (say) grep, which prints output and terminates rather than
 > sticking around to redraw the screen on request?
Since when does EVERY program have to redraw the screen?  I stop and start
compiles, makes, news-readers, mail, etc. and none of them do screen refreshes.

 > The fact is, *both* job control and shell layers are brain-damaged.  Both
 > do the easy part of multiplexing -- centralized input administration --
 > without the hard part -- centralized output administration.  Programs should
 > not have to redraw the screen themselves, when they have done nothing to
 > mess it up!  Job control and shell layers are both cheap plastic imitations
 > of real window systems.
 > -- 
 > 				Henry Spencer @ U of Toronto Zoology

Job control is a helluva lot more than a cheap imitation of a window system.
It is a general method of allowing some user control of system features -- 
time sharing and resource sharing.  Remember that ^Z is only a character hook
to the rather general SIGTSTP signal!  The ability to stop a process is a
very nice features that is NOT unique to BSD Unix (TOPS-10 and TOPS-20 had it).

Further, I think window systems are just fine, but they require VERY special
hardware to give acceptable performance.  Job control frees up system resouces
by allowing processes to be swapped out.  Window systems leave processes lying
around, and clutter the system even more with a window managing process!
The fact that a job can catch or not catch the SIGCONT as it pleases is a very
useful FEATURE!  I would be very annoyed if somebody put screen control into
the kernel (!) and forces a screen update (expensive at 1200 baud) every time
I jumped into and out of a process.

Don't clutter this group with off-the-cuff opinions and snorts!  Both job
control and window systems have their place, and they can even work together.  

-- 
...nz (Neal Ziring at WU ECL  -  we're here to provide superior computing.)

	{seismo,ihnp4,cbosgd}!wucs!nz   OR   nz at wucs.UUCP

    "You could get an infinite number of wires into this !*$$#!?! junction 
                         box, but we usually don't go that far in practice"
				--   Employee of London Electricity Board, 1959