SHL LAYERS

[Guy Harris]

> Advantages of the sysV approach:
> 	o It is "job i/o control" rather than "job cpu control", which
> 	  seems a "cleaner" way to do things.

Although, at times, it is useful to really stop a job.

> 	o There is no reason why programs should not be aware that
> 	  they have been stopped/restarted, because the job-control
> 	  shell could send them signals to tell them about this
> 	  [perhaps using the user-definable signals SIGUSR1 and SIGUSR2].

No, not using SIGUSR1 or SIGUSR2, please.  Those guys are called
user-definable signals because they are to be used by each
*application* as it sees fit, not by something considered part of the
"system" (such as "shl").

> 	  I only send a signal when a job is restarted, 'cos this is the
> 	  useful one

Nope.  You need a signal to tell the process it's having the screen
taken away from it, so that it can clear the screen, turn off the
Tektronix emulation mode in the VT100+Tek emulator terminal referred
to in previous postings, etc..

> 	o The "terminal name" is different for each process (and different
> 	  for the shell, in turn), which can confuse programs that use
> 	  /etc/utmp for fetching terminal names. (getlogin() doesn't work
> 	  too well, either). This is hacked in shl by modifying utmp
> 	  whenever the "current layer" is changed.

This is a depressingly common source of grief in UNIX.  The Sun
window system puts entries in "utmp" every time it opens up a
terminal emulation window, just so that programs using that terminal
emulator as their terminal don't get confused.