SHL LAYERS

[gwyn at brl-smoke.UUCP]

In article <213 at its63b.ed.ac.uk> simon2 at its63b.ed.ac.uk (ECSC68 S Brown CS) writes:
>>In article <5528 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>>> "shl" can do most of the things you probably use 4BSD job control for,
>Not true, if you really mean "shl" here, rather than "sxt devices".

I had in mind that the principal use of job control might be for
putting things "in the background" after-the-fact (as opposed to
doing it in advance with &).  That seems to be the main use of
4BSD job control by many of our users.  "shl" appears to support
this mode of interaction.

Actually, I heard a rumor from a fairly reliable source that the
original "shl" was developed mostly as a joke.  It certainly isn't
the same as 4BSD job control.  On the other hand, the kludgery
necessary in the kernel to support 4BSD-style job control is
aesthetically revolting (and it has changed at least 5 times that
I know of, from evidence collected while Ron's job-control SVR2
Bourne shell was evolving.  Exploiting 4BSD job control (as in
writing a job-control shell) is rather intricate and we keep
finding things that don't quite work right due to subtleties that
an ordinary programmer would be oblivious to.  The best way to
exploit job control, if your system supports it, is to just use
somebody else's job-control shell that works and not try to use
the facilities in your own code (other than the trivial matter of
intercepting signals when the process state changes).