Job Control (a la csh/ksh) from within C

Bennett Todd bet at orion.mc.duke.edu
Sat Oct 7 02:53:41 AEST 1989


In article <1989Oct3.153120.4750 at utzoo.uucp>, henry at 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 at orion.mc.duke.edu



More information about the Comp.unix.wizards mailing list