naim@eecs.nwu.edu (Naim Abdullah) (10/06/89)
I was wondering whether the (future) POSIX compatible Minix have job control ? Naim
ast@cs.vu.nl (Andy Tanenbaum) (10/06/89)
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. Andy Tanenbaum (ast@cs.vu.nl)
maart@cs.vu.nl (Maarten Litmaath) (10/07/89)
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
ast@cs.vu.nl (Andy Tanenbaum) (10/07/89)
In article <3555@solo2.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >I strongly disagree [with the statement that job control is weird] On no. Another religious war. I prefer the PDP-11 MMU actually. To avoid an endless discussion, let me make a tactical retreat, like Galileo did. Job control is wonderful. It is the greatest invention since the binary number system. Faster than a speeding macro. More powerful than a subroutine call. The ultimate in elegance. Nevertheless, I still won't touch it with a barge pole due to the enormous complexity of implementation required by the POSIX standard. Andy Tanenbaum (ast@cs [with the statement that job control is weird]
henry@utzoo.uucp (Henry Spencer) (10/08/89)
In article <3555@solo2.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >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. Well, I don't read wizards any more (no time), so I'd missed that one. However: 1. Comparing a good implementation of a bad idea against a bad implementation of a good one often gives counterintuitive results. 2. People confuse the awesome mess of job control with the simple idea of being able to suspend a process. The two are not identical; see my more recent posting to lang.c and wizards. In any case, you've missed Andy's point. He didn't say job control wasn't useful. He said that it was very complicated and spread messy tentacles everywhere, which is quite true. POSIX 1003.1 is fairly simple and easy to understand if you just ignore everything involving job control. If you don't ignore job control, it makes your head ache pretty quickly. The complexity it adds is REALLY MASSIVE. Read the standard if you don't believe us. Excluding it from a teaching system is sensible, and since job control is optional in POSIX, the system is still standard-conforming. (Andy and I both clearly believe that the horrendous jump in complexity is a symptom of something badly wrong with the concept, but that is another argument entirely.) -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
pcm@iwarpr0.intel.com (Phil C. Miller) (10/10/89)
In article <3546@ast.cs.vu.nl> 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. >Andy Tanenbaum (ast@cs.vu.nl) Andy, I'm not sure I understand your answer because it was so ambiguous. Do you mean that you don't object to job control? ;-) Phil Miller pcm@iwarp.intel.com or {...}!tektronix!ogccse!pcm
ast@cs.vu.nl (Andy Tanenbaum) (10/12/89)
In article <5029@omepd.UUCP> pcm@iwarpr0.UUCP (Phil C. Miller) writes: >Andy, I'm not sure I understand your answer because it was so ambiguous. >Do you mean that you don't object to job control? ;-) I am very flexible. I am willing to publicly espouse whatever position is necessary to minimize the amount the discussion about job control. However until P1003.1 is repealed, the probability of job control appearing in MINIX is 0. Andy Tanenbaum (ast@cs.vu.nl)