Job Control, Shl

[Barry Shein]

>From: dmr%dutoit.uucp at BRL.ARPA
>In the Eighth Edition and also in the System V shl mechanism, each job
>communicates with one of a set of virtual devices multiplexed onto the
>real device.  In SV the multiplexor is in the kernel and is quite
>simple; mainly it just blocks IO from background jobs.  In V8 it is a
>user-level program that talks to an educated terminal.  In SV with 5620
>support, the multiplexor is again a kernel program similar to that used
>by shl (though the the multiplexor is more complicated because it
>speaks in protocol to the terminal).  In none of these is a special
>shell needed...

Although the point is technically correct, the program which manages
shell layers, shl.c, is effectively equivalent to that part of csh
which does job control brought out to another (meta) process. A quick
reading of shl.c should be fairly disturbing to most anyone (I seem to
remember a portion where output is put to a pipe to the child fork to
determine whether it has started yet and hence 'safe' to do the ioctl()s.)
I'm not sure all that magic is particularly 'cleaner' than anything I
see in 4.2, and without the source to that program or a hint about how
this is done it's nearly impossible for a mere mortal to figure out
how to program their own equivalent of shl.c just by the ioctl descriptions.

Sorry if there are any minor errors here but my 3B5 is, as usual, dead.
Maybe the pipe went the other way (parent hung on read, fork wrote upwards.)

I think TOPS-20's ^C had the right idea, basically it is the same as a
BSD ^Z (TSTP) but unless you do something to save the fork (KEEP
cmdname) it is replaced by the next command thus preventing naive
users from backing up a lot of stopped jobs, no one mentioned this
problem on BSD, anyone else have students with 15 stopped lisps
because it doesn't stop when they hit ^C but ^Z works "just fine"?!
Effectively, there is no ^C in the UNIX sense on TOPS-20, only ^Z
as I describe. (obviously this could be controlled by a shell variable.)

Not sure if this has anything to do with window systems though, I suspect
in the end they will push for their own solutions beyond just extrapolations
of current features, otherwise it's the tail wagging the dog. The point of
a window system is, ultimately, to make the user's life easier, not
to show how some current 'job control' can be pushed to its limits.

	-Barry Shein, Boston University