Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!ames!ll-xn!mit-eddie!apollo!pato From: pato@apollo.COM (Joe Pato) Newsgroups: comp.sys.apollo Subject: Re: some questions for the gurus. Message-ID: <3e9fa036.12edf@apollo.COM> Date: 22 Sep 88 17:54:00 GMT References: <8809152050.AA02337@richter.mit.edu> <1988Sep20.112851.1047@mntgfx.mentor.com> Reply-To: pato@apollo.COM (Joe Pato) Organization: Apollo Computer, Chelmsford, MA Lines: 28 In article <1988Sep20.112851.1047@mntgfx.mentor.com> rreed@mntgfx.UUCP (Robert Reed) writes: . . . >I'm not sure this is always true, from the DOMAIN/IX csh man pages: > > Commands started in-process cannot be suspended or manipulated using > the csh job-control facilities. > >This is a restriction imposed on jobs started under an existing csh. If >the process has been started by doing a crp, even this may not be >possible. Do any of our comrades from Apollo know the answer to this? When a DOMAIN/IX csh is run in-process it uses pgm_$invoke to run subcommands instead of using fork/exec. Subcommands run in this mode are actually running in the same process as the csh and therefore csh job contol features (which contol a child process) are inoperable (there is no child process). It is possible, but clumsy, to use job control when using a csh through crp. Job control can be enabled by unsetting the INPROCESS environment variable. (or setting the csh "inprocess" variable to 0.) Cshells running in a crp environment do not default to this state because crp does not catch the tty stop signal (SIGTSTP). As a result it never forwards the signal to the remote process (the crp process itself stops). If you want to be able to use job control on the remote node you have to have some mechanism to send the signal remotely. (It is sufficient, but clumsy, to create another remote process and use kill...) Joe Pato UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato Apollo Computer Inc. NSFNET: pato@apollo.com