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

[terryl at tekcrl.LABS.TEK.COM]

In article <20040 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>-In article <320 at sopwith.UUCP> snoopy at sopwith.UUCP (Snoopy) writes:
>->Henry, Henry, Henry.  Job control is necessary even with a window system.
>->Otherwise how does one stop a process without killing it?
>
>In article <1989Oct6.164830.5856 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer)
>answers:
>-One tells the system to suspend it.  Yes, this does require some sort of
>-facility for doing so.  No, it does not require mysterious signals with
>-bizarre semantics, magic control characters, or any of the other sludge
>-that job control brings along.  You've got other windows, remember -- you
>-can use one of them to request the suspension, and to fiddle with the
>-process thereafter.
>
>How do I get the second window on my H19 here?
>
>One of the things that bothers me about many of these fancy windowing
>systems is that there is no way to dial in and use them.


      Well, I do have a window system, and I still prefer the <insert-fave-
funky-description> job control way. Why??? Well, even if I do have another
window open to the system in question, that means I have to find the other
window, make sure it isn't doing anything, then issue the appropriate command
to suspend the process (but wait!!! You need a process ID!!! Quick!!! What
was that process ID???) This takes time, and by the time I figure all of this
out, the reason I wanted to suspend the process in the first place is probably
no longer true, so I'll have to KILL the process, and start all over again.

     Contrast that with the job control method; I'm probably already typing
into the window in question, so all it takes is ONE keystroke, and the (almost)
immediate feedback about the process being stopped is very gratifying. With
the other alternative, I'll probably have to go back to the other window and
verify that the process did actually get suspended.

     So what scenario do I encounter frequently?? Well, I do software develop-
ment in a cross environment (well, actually kernel development, but I do a
fair amount of user code, too), and I'm very forgetful to write out changes to
a file before typing `make', so quite often, I have to suspend the make, and
go back to the other window and write out the changes. Then, I can go back to
the window in question and unsuspend the make so it can continue. Job control
makes this VERY easy to do, and it's quick enough.

     And what if one doesn't have another window open to the system in question?
Well, forget about anything but job control, because by the time one can pop up
another window and issue the appropriate commands, it will definitely be too
late to stop the process in time to do the things one wants....

     However, I will concede Henry's point about sludge going along with job
control. Just take a look at sys/kern_sig.c (for BSD systems; I have no idea
what the counterpart is for a SYSV system...); not very pretty code, IMHO.

     As an aside, one can abuse window systems (again, IMHO). Personally, I
can't keep more than 6-7 windows up on the screen without constantly searching
for the right window to do what I want. I know people who routinely keep 15-20
windows on the screen (I'm not joking; I know people like this...), and even
by iconifying(sp?) some of them, they still spend quite a bit of time searching
for the right window.....


				Terry Laskodi
				     of
				Tektronix