multiplexing terminals...

[Doug Gwyn]

In article <574 at codas.ATT.UUCP> mikel at codas.ATT.UUCP (Mikel Manitius) writes:
-> "Shell layers" refers to "shl", which is NOT the same as DMD "layers".
-> Some people find "shl" useful; it doesn't require any special terminal.
-> Its main problem is that it merely multiplexes the terminal for several
-> concurrent processes, which have no way to tell what may be visible on
-> the current display.  A full window manager solves this problem.
-
-You can very easily tell what is on your screen, if you do "stty loblk".
-This blocks processes which try to output to the terminal, if they are
-not in the current layer. When the layer becomes current, then they job
-is unblocked, and you may get flooded with output.

Rong; that's not what I was talking about.  Try running two concurrent
"vi"s under "shl" and see what good "stty loblk" does you.

-In my opinion, this is still not as nice as berkeley's job control, but
-to get that, you must give up other things....

Job control is a massive hack that doesn't work well in a general
environment where daemons have equal rights with humans, where
there are several candidates for a process's "controlling terminal",
where it is not clear whether a net port constitutes a "terminal" or
not, etc.  Like many Berkeley features, it is nice so long as one lives
within the restricted usage model that it was based on.  In any case,
HP-UX has a System V-compatible implementation of BSD-style job
control.  What are the "other things" one supposedly has to give up?