Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!star.cs.vu.nl!maart
From: maart@cs.vu.nl (Maarten Litmaath)
Newsgroups: comp.os.minix
Subject: Re: Job Control in POSIX compatible Minix ?
Message-ID: <3555@solo2.cs.vu.nl>
Date: 6 Oct 89 22:06:47 GMT
References: <5490006@eecs.nwu.edu> <3546@ast.cs.vu.nl>
Organization: V.U. Informatica, Amsterdam, the Netherlands
Lines: 78

ast@cs.vu.nl (Andy Tanenbaum) writes:
\In article <5490006@eecs.nwu.edu> naim@eecs.nwu.edu (Naim Abdullah) writes:
\>I was wondering whether the (future) POSIX compatible Minix
\>have job control ?
\>
\>   Naim
\
\No. Non. Nee. Nein. Nyet.
\In short, absolutely, definitively, no.  I have read the POSIX standard
\quite carefully.  The job control enormously complicates everything.  It
\rears its ugly head in all kinds of funny places.  I want to keep the
\system comprehensible, and adding a weird feature like job control is not
                                     ^^^^^^^^^^^^^
\the way to go.

I strongly disagree.  The next included article I found on comp.unix.wizards
just today.  I think Henry Spencer will have something to say about it, but
this article makes clear the advantages of (properly implemented) job control.
Article follows.

From: bet@orion.mc.duke.edu (Bennett Todd)
Newsgroups: comp.unix.wizards
Subject: Re: Job Control (a la csh/ksh) from within C
Message-ID: <15722@duke.cs.duke.edu>
Date: 6 Oct 89 16:53:41 GMT
References: <1719@zen.co.uk> <1989Oct3.153120.4750@utzoo.uucp>
Sender: news@duke.cs.duke.edu
Reply-To: bet@orion.mc.duke.edu (Bennett Todd)
Followup-To: comp.unix.wizards
Organization: Diagnostic Physics, Radiology, DUMC
Lines: 42

In article <1989Oct3.153120.4750@utzoo.uucp>,
	henry@utzoo (Henry Spencer) writes:
>Well, the *proper* way to control jobs is not to fool around with
>abominations like BSD job control, but to do something sensible like a
>window system that lets you interact with multiple processes without
>ornate kludges.

This isn't the first time I've heard this viewpoint expressed. I can't
say I agree. I use various window systems (Suntools, X, and my favorite
by a wide margin, MGR) and I *also* use job control, and I can't see how
having a good window system makes job control redundant.

Often I'll put something to sleep and use the parent shell because I'd
rather do that than put up with the wait and memory consumption to make
another window with another shell, just to run a simple command. Yes,
this could be handled with windows. I haven't seen a window system yet
that wasn't much slower and more cumbersome and laborious than job
control for a simple operation like this, and besides I don't have to
switch my attention to another context on the screen. I like job control
better for some such tasks. Further, I rarely open a new window for a
long-running program if it isn't going to want to be interactive; I
prefer to launch the thing in the background. If I later come to
discover that it really *was* interactive I can change my mind and bring
it back to the foreground.

More importantly, the general facility of having a nice accessible
stopped state in the kernel, together with signals to move processes or
process groups between runnable and stopped states, makes things
possible, even *easy*, that I don't know how to do otherwise. The
general case is a process that is going to be needing some resource
soon. With job control you can stop the process in its tracks, make the
resource available, and then allow it to resume. Standard practice
around here is to run a program that is going to be eating some disk
space in one window, and keep an eye on available free space in another
window. You can make sure there is plenty of space before you start, but
our UNIX systems are multiuser, and reasonably often someone else will
start up something that eats dozens of megabytes in the middle of one of
your runs. So, you stop your process, go and work out an agreement with
the person who is crowding into your space, and restart it. Job control
has more uses than terminal I/O multiplexing.

-Bennett
bet@orion.mc.duke.edu
-- 
"Sometimes it seems Marvin wrote MINIX while Andy was playing Donald Duck's
Playground on Suzanne's computer."  (Benno van den Brink)  | mcvax!botter!maart