Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: System V job control idea
Message-ID: <5960@brl-smoke.ARPA>
Date: Fri, 5-Jun-87 02:51:45 EDT
Article-I.D.: brl-smok.5960
Posted: Fri Jun  5 02:51:45 1987
Date-Received: Tue, 9-Jun-87 02:37:47 EDT
References: <337@tdi2.UUCP> <757@mcgill-vision.UUCP> <165@elan.UUCP> <1662@munnari.oz> <2245@hoptoad.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 13

In article <2245@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>In article <1662@munnari.oz>, kre@munnari.oz (Robert Elz) writes:
>> If you have job control, a suitably authorised user (ie: root)
>> can pick a random process and stop it, to be continued later.
>I wish this was true.  Trouble is, the parent of that process will
>receive a report that it has stopped.

Elz may have had in mind sensible job control facilities, not 4BSD.
E.g., /proc filesystem.
After several years of fighting more than a half-dozen small but
important changes to the way terminals, process groups, vhangup,
etc. operate and more importantly interact, I'm now convinced
that the 4BSD implementation of job control is not the right approach.