SHL LAYERS

[Mike Stump]

In article <161 at piaget.UUCP> jc at piaget.UUCP (John Cornelius, System Manager) writes:
>I suspect that if a detached process wants to output to the
>terminal as the standard error device it will do so without regard
>to whether the terminal is attached.  This could cause some rather
>interesting screens.
>
>I do not believe that there is actually a SIGSUSP signal in
>System V so the process has to run until it wants to do I/O to
>the terminal.

Just a slight fix here:
	Shl does work, but you can have only (did I say only?)
seven shells running under it.  For some odd reason our copy
of Korn Shell does not want to seem to run under shl,
(anybody want to comment?) but Bourne Shell, runs fine.  Then
again we are running SVR2 V2.0, 2.1 fixed some bugs in 2.0,
so I would expect Korn to work with shl in 2.1.  There is
input blocking, the ability for shl to stop other shells from
reading from the terminal, and there is optional output
blocking via the `block' command in shl, and `stty loblk'.
To get out of blocked mode, you can `unblock' in shl, or
`stty -loblk' in the shell in which you want unblockedness.
-- 
Mike Stump, Cal State Univ, Northridge Comp Sci Department
uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!aeusemrs