Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekcrl!terryl From: terryl@tekcrl.LABS.TEK.COM Newsgroups: comp.unix.wizards Subject: Re: Job Control (a la csh/ksh) from within C Message-ID: <4802@tekcrl.LABS.TEK.COM> Date: 9 Oct 89 18:09:00 GMT References: <1719@zen.co.uk> <1989Oct3.153120.4750@utzoo.uucp> <320@sopwith.UUCP> <1989Oct6.164830.5856@utzoo.uucp> <20040@mimsy.UUCP> Reply-To: terryl@tekcrl.LABS.TEK.COM Organization: Tektronix, Inc., Beaverton, OR. Lines: 63 In article <20040@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >-In article <320@sopwith.UUCP> snoopy@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@utzoo.uucp> henry@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 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