mat@emcard.UUCP (Mat Waites) (12/14/88)
How do you activate csh job control under HP-UX? (9000/8xx) Is is available? If not, when will it be? Thanks, anyone, Mat -- W Mat Waites gatech!emcard!mat 8-5 ET: (404) 727-7197
daveh@hpubvwa.HP.COM (Dave Highley) (12/16/88)
To turn it on put "stty susp \^Z" in the /etc/profile and /etc/csh.login file.
shankar@hpclscu.HP.COM (Shankar Unni) (12/17/88)
> How do you activate csh job control under HP-UX? (9000/8xx) % stty susp ^z #or your favourite job-control character > Is is available? If not, when will it be? Yes. Now (actually, for the past couple of years). -- Shankar.
maddog@anuck.UUCP (j.j.tupper) (12/22/88)
In article <1340038@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >> How do you activate csh job control under HP-UX? (9000/8xx) > >% stty susp ^z #or your favourite job-control character What about 9000/3xx?
bd@hp-sde.SDE.HP.COM (Bob Desinger) (12/24/88)
j.j.tupper (maddog@anuck.UUCP) asks:
> What about [job control under] 9000/3xx?
Move your mouse pointer to your other terminal-emulator window.
(It's not on the s300. But I sure hope it gets there someday!)
-- bdross@ziebmef.uucp (Ross Ridge) (12/27/88)
In article <11590012@hpubvwa.HP.COM> daveh@hpubvwa.HP.COM (Dave Highley) writes: >To turn it on put "stty susp \^Z" in the /etc/profile and /etc/csh.login file. Does anybody know if the file "/etc/csh.login" is suported by the HP 9000 Series 200 csh? (Note: I'm not asking if job control works on the 200, I assume it doesn't) Ross Ridge P.S. Please reply to either ross@ziebmef or ross@watcsc (!watmath!watcsc!ross) as I seldom get the chance to read this group. -- l/ uunet!attcan!lsuc!ncrcan!ziebmef!ross // [OO] or just call me Ross for short... [oo] -()- -()- db 6502 assembly forever! //
rml@hpfcdc.HP.COM (Bob Lenk) (12/30/88)
> Does anybody know if the file "/etc/csh.login" is suported by the HP 9000 > Series 200 csh? If you mean series 300, yes. If you actually mean series 200, I'm pretty sure it's supported in the 5.1 release, but not the 2.x releases (any csh revision 27.2 or greater (try "what /bin/csh") should support it). Bob Lenk hplabs!hpfcla!rml rml%hpfcla@hplabs.hp.com
markf@hpfcse.HP.COM ( Mark Fresolone ) (12/31/88)
>> What about [job control under] 9000/3xx? >Move your mouse pointer to your other terminal-emulator window. >(It's not on the s300. But I sure hope it gets there someday!) There is something akin to job control on S300 for ASCII terminals - it is 'shl'. Try: $ stty swtch \^z $ shl You can now create "sessions" >>> c sess-a [layer sess-a created] [running layer sess-a] sess-a_ At this point, you are in a shell, "sess-a" is your prompt (a .kshrc might use it to make a nicer PS1). Any time you want to allow a foreground program to continue while you make better use of you time elsewhere on HP-UX, just type ^z. You will get another shl prompt (">>>"), and can "c"reate a new session, or "r"esume another old one. ("h"elp should get you fully functional.) Shl uses a separate pty for each session, so stty settings are preserved individually. Shl is functionally similar to an AT&T tool of the same name. It is built on a library which uses pty's to emulate an AT&T pseudo-driver called SXT. Mark / hpfcse![hpupnja!]markf
rml@hpfcdc.HP.COM (Bob Lenk) (01/04/89)
> >> What about [job control under] 9000/3xx? > >Move your mouse pointer to your other terminal-emulator window. > >(It's not on the s300. But I sure hope it gets there someday!) > > There is something akin to job control on S300 for ASCII terminals - > it is 'shl'. Actually I consider shl more akin to windows than to job control. Like windows, it can be used as a substitute for job control (job control can also be used as a substitute for windows). You can expect the s300 to have job control in a future release. Bob Lenk hplabs!hpfcla!rml rml%hpfcla@hplabs.hp.com Disclaimer: This is a posting from me as an individual, not in any official capacity for my employer.
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
decot@hpisod2.HP.COM (Dave Decot) (10/05/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... If indeed you weren't really looking for knee-jerk pontification on something vaguely related to your question, here's an answer that is probably closer to what you wanted: See the Summer 1986 USENIX proceedings for the following paper (p. 459): A System V Compatible Implementation of 4.2BSD Job Control David C. Lennert Hewlett-Packard Company Information Technology Group This paper gives an overview of how process groups and controlling terminals are handled in System V and 4.2BSD and then discusses the effect 4.2BSD job control has on these things. A modified 4.2BSD interface is discussed which supports 4.2BSD job control functionality but in a way which allows AT&T System V compatibility. This interface has been implemented in Hewlett-Packard's [operating] system, HP-UX. In particular, see the section "6.4. HP-UX Typical Scenario" on page 472. Dave "windows: Ability to suspend and resume processes: not found" Decot decot%hpda@hplabs.hp.com
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
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.
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
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
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