jsalter@slo.uucp (James Salter) (09/09/89)
In article <1989Oct6.164830.5856@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >One tells the system to suspend it. [...] >[...] You've got other windows, remember -- you >can use one of them to request the suspension, and to fiddle with the >process thereafter. Sure. And on an 11" monitor, those windows will look like stamps. Give me job control, any day. >Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology jim/jsalter IBM AWD T465/(415)855-4427 VNET: JSALTER at PALOALTO UUCP: ..!uunet!ibmsupt!jsalter Disc: Any opinions are mine. IP: ibmsupt!jsalter@uunet.uu.net "PS/2 it, or DIE!" -- me
vic@zen.co.uk (Victor Gavin) (09/28/89)
I've been trying to write a C program to handle pipelines and have found that my understanding of how job control works is sadly lacking. Can anyone point me towards a book/manual/paper which explains how to control jobs *properly* from within a C program? vic -- Victor Gavin Zengrange Limited vic@zen.co.uk Greenfield Road ..!mcvax!ukc!zen.co.uk!vic Leeds England +44 532 489048 LS9 8DB
henry@utzoo.uucp (Henry Spencer) (10/03/89)
In article <1719@zen.co.uk> vic@zen.co.uk (Victor Gavin) writes: >...my understanding of how job control works is sadly lacking. >Can anyone point me towards a book/manual/paper which explains how to >control jobs *properly* from within a C program? 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. However, that probably isn't what you wanted... -- Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology shortsighted (and improving). | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
snoopy@sopwith.UUCP (Snoopy) (10/04/89)
In article <1989Oct3.153120.4750@utzoo.uucp> henry@utzoo.uucp (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. However, that probably isn't what you wanted... Henry, Henry, Henry. Job control is necessary even with a window system. Otherwise how does one stop a process without killing it? | Nature is blind; Man is merely | shortsighted (and improving). Distance != time. _____ /_____\ Snoopy /_______\ cse.ogc.edu!sopwith!snoopy |___| sun!nosun!qiclab!sopwith!snoopy |___| uunet!tektronix!tessi!illian!sopwith!snoopy
henry@utzoo.uucp (Henry Spencer) (10/06/89)
In article <320@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) 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. However, that probably isn't what you wanted... > >Henry, Henry, Henry. Job control is necessary even with a window system. >Otherwise how does one stop a process without killing it? 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. -- Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology shortsighted (and improving). | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bet@orion.mc.duke.edu (Bennett Todd) (10/06/89)
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
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/07/89)
In article <15722@duke.cs.duke.edu> bet@orion.mc.duke.edu (Bennett Todd) writes: >Job control has more uses than terminal I/O multiplexing. In fact, there are those among us who think process control is best done in ways other than by signals generated in response to certain keystrokes. See the famous "Processes as Files" paper in one of the USENIX conference proceedings for more about this.
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/07/89)
In article <10041@venera.isi.edu> raveling@isi.edu (Paul Raveling) writes: > There've been a number of decent-to-good examples of > this sort of facility, but I haven't seen one yet in > a Unix system. The /proc filesystem and associated ioctls has existed for quite some time. You should be seeing more commercial UNIX implementations with such facilities. (Silicon Graphics has been shipping one for over a year now.) > P.S.: It's easier to implement good process/job control > if you slip a more capable kernel underneath Unix instead > of building a kludge over it. This is a false dichotomy. The UNIX kernel can be reengineered to properly handle such things, and in fact it has been.
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/07/89)
In article <20040@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >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. So use one that DOES work over dialup. Many of our employees have 5620s (or 630s if we had any to spare) at home and use them in "layers" (windowing) mode. Your H19 is probably a hopeless case, but even so there are window managers that work with ordinary CRT terminals. I don't know how good they are (I suspect: not very).
raveling@isi.edu (Paul Raveling) (10/07/89)
In article <1989Oct6.164830.5856@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <320@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) 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. However, that probably isn't what you wanted... > > > >Henry, Henry, Henry. Job control is necessary even with a window system. > >Otherwise how does one stop a process without killing it? > > 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. Right on! There've been a number of decent-to-good examples of this sort of facility, but I haven't seen one yet in a Unix system. P.S.: It's easier to implement good process/job control if you slip a more capable kernel underneath Unix instead of building a kludge over it. ---------------- Paul Raveling Raveling@isi.edu
chris@mimsy.UUCP (Chris Torek) (10/07/89)
-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. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (10/07/89)
In article <20040@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >How do I get the second window on my H19 here? ;-) From GnuEmacs: M-x shell (or preceded by a "M-x rename-buffer <cr> shell-1" for moving the first shell out of the way to get the second.) >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. One thing I tended to do alot (at 1200 baud at least) is use GnuEmacs as my windowing system. Free ksh-like patches to shell.el from anon ftp to mgm.mit.edu. -wolfgang Wolfgang Rupprecht ARPA: wolfgang@mgm.mit.edu (IP 18.82.0.114) TEL: (703) 768-2640 UUCP: mit-eddie!mgm.mit.edu!wolfgang
chris@mimsy.UUCP (Chris Torek) (10/07/89)
>>>... 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 [not necessarily via signals, etc.]. >... You've got other windows, remember ... In article <20040@mimsy.UUCP> I wrote: >How do I get the second window on my H19 here? I should mention that I am not saying that signals, ^Z, etc., are *the best* way to do job control, or even *the only* way, but I *am* saying that, at least for now, they are better than ways that require windows. (There are a whole series of things I think are wrong with the current *and* the POSIX job control implementations. For instance, process groups should be allocated by the kernel, and it should be possible to for a process to stop itself without sending itself a signal.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
terryl@tekcrl.LABS.TEK.COM (10/10/89)
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 <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
simon@vision.UUCP (Simon Taylor) (10/10/89)
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. No problem, we regularly use our windowing product (PC-Connect) over 2400 and 1200 baud modem links..... in fact it there are a number of advantages in that you can switch from job to job without having any data passing over the comms link, and since PC-Connect uses the PC running Microsoft Windows to handle the display, changing the size of windows etc. similarly does not require any data to pass over the comms link. This means that overall it makes a typical modem session a lot easier to handle. Simon Taylor UUCP : simon@vision.uucp VisionWare Ltd BANGNET : ...!uunet!mcvax!ukc!vision!simon Systime House PHONE : +44 532 529292 Ex. 2458 Leeds Business Park FAX : +44 532 526614 Leeds LS27 0JG TELEX : 556283 SYSTIM G England
caa@garnet.ssd.cdc.com (Charles A. Anderson) (10/11/89)
chris@mimsy.UUCP (Chris Torek) writes: >In article <20040@mimsy.UUCP> I wrote: >>How do I get the second window on my H19 here? The same way I get a second, and third, and fourth...on a H19, run screen...ok so it's not a real window, it's a separate screen, but I think thats better on a H19 anyway. >-- >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) >Domain: chris@cs.umd.edu Path: uunet!mimsy!chris -- Charles Anderson | caa@garnet.ssd.cdc.com \ Disclaimer: I said what? ----------------/ caa@midgard.mn.org \ But CDC didn't. I woke up this morning and it was nice out, so I left it out.
madd@bu-cs.BU.EDU (Jim Frost) (10/12/89)
In article <20040@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: |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. See "At Home With X11/NeWS" in the June 1989 USENIX Proceedings. One of the things that bothers me about most windowing systems is that they need a lot of communication between server/client, which is painful over slow connections. The NeWS technique is better since many operations are local to the server and need no communication at all. I wouldn't have picked postscript for my language, though. Of course you still need that bitmapped terminal at home for that, but then again we all have one, right ;-). jim frost software tool & die madd@std.com
henry@utzoo.uucp (Henry Spencer) (10/12/89)
In article <2491@ibmpa.UUCP> jsalter@slo.UUCP (James Salter) writes: >>[...] You've got other windows, remember ... >Sure. And on an 11" monitor, those windows will look like stamps. Well, if you *insist* on having them all on the screen at a time, of course they will. Particularly on a 24x80 terminal, you wouldn't. Call them up when you need them. -- 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
dhesi@sun505.UUCP (Rahul Dhesi) (10/13/89)
In article <1989Oct12.022407.7989@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Well, if you *insist* on having them all on the screen at a time, of >course they will. Particularly on a 24x80 terminal, you wouldn't. >Call them up when you need them. Drat! Got to get that 9600 bps modem fixed. Oops...you need *two* of them! Actually it turns out that job control is useful even in a windowing environment. With multiple windows, you can use job control in many places instead of only one. Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
allbery@NCoast.ORG (Brandon S. Allbery) (10/14/89)
As quoted from <20040@mimsy.UUCP> by chris@mimsy.UUCP (Chris Torek): +--------------- | 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. +--------------- Sigh. Chris, MultiView works fine over a serial port, albeit at a slight loss of speed. (I'm talking 2400 baud here, not V.32.) I suspect screen will work as well, although a curses-based windowing utility will probably be a bit more painful. Then again, watching MultiView dump core when it tries to work with a Falco 5000 isn't a whole lot of fun, either. :-( VAGUELY RELATED QUESTION: How does one go about using System V pty's accessed through the Streams clone interface? I can't quite figure out how one gets from /dev/pty to a master *and* a slave device, unless one opens /dev/pty, fstat()'s the file descriptor, and mknod()'s the slave -- which sounds uuuuuuuugly to me, requires root permissions (for the mknod), and you have to know the major number for the ttypX device. Is there in fact a relatively clean way to do this which doesn't require me to hard-code a major device number and make my program setuid, or is it as badly designed as it seems to be at first glance? Thanks in advance, ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
allbery@NCoast.ORG (Brandon S. Allbery) (10/14/89)
As quoted from <11240@smoke.BRL.MIL> by gwyn@smoke.BRL.MIL (Doug Gwyn): +--------------- | Your H19 is probably a hopeless case, but even so there are window | managers that work with ordinary CRT terminals. I don't know how | good they are (I suspect: not very). +--------------- I haven't yet gotten a version of our OS with working pty's (and wouldn't know how to use them if I did; see my previous message in this thread -- I'm not convinced that the clone device is a reasonable way to make ptys), so I haven't played with "screen" yet. I *do* use the commercial product JSB MultiView at work on VT220 clones. It has some warts in the version we have: it tends to mishandle the status line (which can lead to a core dump, producing an immediate end-of-session as all your open windows are blasted into oblivion); it can't handle complex terminals like the Falco 5000 which uses a sort of combined Wyse-60/VT300 escape sequence set with enhancements -- give it all the equivalences for escape sequences and it dumps core; it doesn't support terminals with magic cookies (that's okay; neither do I ;-); sometimes its screen management is, shall we say, erratic. But by and large it's quite usable; I find it invaluable. Please note that I haven't missed job control, even though I use systems (e.g. uunet) which have it. I have heard of at least one non-commercial program (BOSS) which is supposed to be similar to MultiView. (I'm interested in more information on it; I like my status line ;-) In any case, it *is* possible to have usable windowing on character-based terminals. Sure, you can't open a window with a graphical load average indicator in it, but you can do a heck of a lot with it nonetheless. (In particular, it's *the* answer to Mac DA's and PClone TSR's in the Unix world.) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
raveling@isi.edu (Paul Raveling) (10/17/89)
In article <11237@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > > > P.S.: It's easier to implement good process/job control > > if you slip a more capable kernel underneath Unix instead > > of building a kludge over it. > > This is a false dichotomy. The UNIX kernel can be reengineered to > properly handle such things, and in fact it has been. My original comment was poorly qualified. What I meant to suggest was actually replacing a Unix kernel with a different kernel plus a Unix kernel interface layered between the new kernel and existing Unix-based software. A limited example was EPOS, which didn't have a full Unix interface layer, but it did have enough of one to allow compiling & running the old V6 icheck program without source changes. This was needed because one of the 3 file systems that EPOS supported was the Unix (V6) file system. An intriguing idea would be multiple interface layers to support different dialects of Unix (Sys V, BSD, HP-UX,...) on a per-job or per-process basis. ---------------- Paul Raveling Raveling@isi.edu
friedl@bang.UUCP (Steve Friedl) (10/17/89)
> The /proc filesystem and associated ioctls has existed for quite some > time. You should be seeing more commercial UNIX implementations with > such facilities. (Silicon Graphics has been shipping one for over a > year now.) The AT&T 3B15 has had /proc on its Sys V Rel 3.1 machines for over a year as well. Too bad we don't have truss :-(. Steve -- Stephen J. Friedl / Software Consultant / Tustin, CA / + 714 544 6561 3B2-kind-of-guy / {attmail uunet}!vsi!friedl / friedl@vsi.com Replies to vsi!bang!friedl might get lost, please use vsi!friedl
oj@apollo.HP.COM (Ellis Oliver Jones) (10/20/89)
In article <10163@venera.isi.edu> raveling@isi.edu (Paul Raveling) writes: > An intriguing idea would be multiple interface layers > to support different dialects of Unix (Sys V, BSD, HP-UX,...) > on a per-job or per-process basis. Intriguing indeed. You could use an environment variable (SYSTYPE, say) to control, for each shell and process, which U***x variant was in force. You could come up with a way to tag executable images with a RUNTYPE which was distinct from the SYSTYPE, to allow program developers to work in one environment and program users to work in another without excessive confusion. You could construct your file system so that directories like /usr contain soft links through the SYSTYPE environment variables, like these: lrwxrwxrwx 1 root 21 Oct 13 19:14 bin -> ../$(SYSTYPE)/usr/bin lrwxrwxrwx 1 root 24 Oct 13 19:14 catman -> ../$(SYSTYPE)/usr/catman lrwxrwxrwx 1 root 25 Oct 13 19:14 include -> ../$(SYSTYPE)/usr/include lrwxrwxrwx 1 root 21 Oct 13 19:14 lib -> ../$(SYSTYPE)/usr/lib and the actual /usr/bin files could really be found, in several flavors, in places like /bsd4.3/usr/bin and /sys5.3/usr/bin . Great idea! I didn't have to laboriously fake the above directory listing. Rather, I just asked my computer for it. /Ollie Jones (speaking for myself, not necessarily for HP's Apollo Systems Division)
gwyn@smoke.brl.mil (Doug Gwyn) (06/30/91)
In article <1991Jun29.084246.29248@ITcorp.com> geoff@ITcorp.com (Geoff Kuenning) writes: >My recommendation (which will be ignored, of course) is to trash the >horrible BSD design, keeping only the ability to stop a job, and >implement System V's "shl" for the use of those people who don't have >windows. We should be so lucky. I don't think that's really a good approach, either, although it is cleaner and safer than the BSD method. What would be better would be for the OS to provide the fundamental mechanisms for implementing job-control sort of applications, in as clean and general a manner as possible. Then something like "shl" could be implemented, but also so could other approaches. For example: /proc/<PID> provides complete process control abilities and, importantly, applies access checks in a manner consistent with the entire OS permissions model. People with windowing systems could run a little process monitor utility in one window and use that utility to stop, examine, and resume processes, entirely free of concern about undesirable interactions in the window attached to the process itself (unlike keyboard signal-initiated kinds of job control). And/or: fork() returns a message-channel file descriptor rather than a PID, and that f.d. can be passed around among cooperating processes, and used to apply ioctls to the process itself to control it. I'm sure there are other possibilities. The key is not to focus too narrowly on existing implementations, when radically different methods might be much better.
bzs@world.std.com (Barry Shein) (06/30/91)
Anyone who has seen the source to shl probably cringes to hear it
recommended. I really liked the part where they write some random byte
down the pipe and then the child waits for it to arrive to know it's
safe to proceed. Now there was a design...
--
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDed@mtxinu.COM (Ed Gould) (07/01/91)
>Anyone who has seen the source to shl probably cringes to hear it >recommended. At the first Washington Conference (also the last event to be sponsored jointly by USENIX and [then] /usr/group), I remember chatting with someone from AT&T, whom I didn't know, and whose name I have long since forgotton. He admitted that shl was his idea. However, he followed that statement by remarking, quite seriously, that he had been joking at the time. He also said that he was more careful about his jokes after that... -- Ed Gould No longer formally affiliated with, ed@mtxinu.COM and certainly not speaking for, mt Xinu. "I'll fight them as a woman, not a lady. I'll fight them as an engineer."