UNIX Futures

[P. D. Guthrie]

In article <1524 at wucs.UUCP> nz at wucs.UUCP (Neal Ziring) writes:
>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.
On System V layers?  I highly doubt it.  That was the context of Henry's
posting.  This (as was explained before)  is *not* possible with the
current switch implementation as a signal is not generated.  It might be
an idea to have the tty driver generate SIGUSR1 when a switch character
is entered - would break quite a bit of existing software though.
>
> > > 	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 2layers 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).
Yes,  but in true windowing system this is unnecessary and I don't find
myself missing it at all.
>
>Further, I think window systems are just fine, but they require VERY special
>hardware to give acceptable performance.  
Not true.  See the BLTJ article on the DMD's.
>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.
I do admit that there needs to be an extra signal which can be sent to a
process when the size of the window is changed.  This could be handled
at a graphics library level though.
>
>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.  
Agreed.
>
>-- 
>...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


-- 

Paul Guthrie				`When the going gets weird,
ihnp4!ihdev!pdg				 The weird turn pro'
					  - H. Thompson