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