Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!yale.edu!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: job control (was: How to mess up your tty)
Message-ID: <16585@smoke.brl.mil>
Date: 30 Jun 91 00:23:11 GMT
References: <2997.Jun2704.59.0991@kramden.acf.nyu.edu> <1991Jun29.084246.29248@ITcorp.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 29

In article <1991Jun29.084246.29248@ITcorp.com> geoff@ITcorp.com (Geoff Kuenning) writes:
>My recommendation (which will be ignored, of course) is to trash the
>horrible BSD design, keeping only the ability to stop a job, and
>implement System V's "shl" for the use of those people who don't have
>windows.  We should be so lucky.

I don't think that's really a good approach, either, although it is
cleaner and safer than the BSD method.

What would be better would be for the OS to provide the fundamental
mechanisms for implementing job-control sort of applications, in as
clean and general a manner as possible.  Then something like "shl"
could be implemented, but also so could other approaches.  For example:

/proc/<PID> provides complete process control abilities and, importantly,
applies access checks in a manner consistent with the entire OS permissions
model.  People with windowing systems could run a little process monitor
utility in one window and use that utility to stop, examine, and resume
processes, entirely free of concern about undesirable interactions in the
window attached to the process itself (unlike keyboard signal-initiated
kinds of job control).  And/or:

fork() returns a message-channel file descriptor rather than a PID, and
that f.d. can be passed around among cooperating processes, and used to
apply ioctls to the process itself to control it.

I'm sure there are other possibilities.  The key is not to focus too
narrowly on existing implementations, when radically different methods
might be much better.