Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.unix.questions Subject: Re: SHL LAYERS Message-ID: <5562@brl-smoke.ARPA> Date: Fri, 23-Jan-87 18:50:13 EST Article-I.D.: brl-smok.5562 Posted: Fri Jan 23 18:50:13 1987 Date-Received: Mon, 26-Jan-87 01:41:42 EST References: <1324@cadovax.UUCP> <5528@brl-smoke.ARPA> <380@oblio.UUCP> <213@its63b.ed.ac.uk> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 25 In article <213@its63b.ed.ac.uk> simon2@its63b.ed.ac.uk (ECSC68 S Brown CS) writes: >>In article <5528@brl-smoke.ARPA>, gwyn@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).