Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ncr-tp.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!ittvax!dcdwest!sdcsvax!sdcc3!sdcc6!ncr-tp!greg
From: greg@ncr-tp.UUCP (Greg Noel)
Newsgroups: net.unix-wizards
Subject: Bug in csh? (exec v. job control)
Message-ID: <175@ncr-tp.UUCP>
Date: Tue, 23-Apr-85 17:28:26 EST
Article-I.D.: ncr-tp.175
Posted: Tue Apr 23 17:28:26 1985
Date-Received: Fri, 26-Apr-85 05:21:57 EST
Reply-To: greg@ncr-tp.UUCP (Greg Noel)
Organization: NCR Corporation, Torrey Pines
Lines: 22

> From: anton@ucbvax.ARPA (Jeff Anton)
> For those few who understand how the "process group" has been abused
> in the name of job control this should be understud.
>
> The new csh changed the process group of the terminal then the
> csh execs foobar and the process dies.  The vi wakesup [sic] from the
> forked process dying and tries to print something.  The vi's [sic] process
> group now does not match the terminals so the system sends the process
> group a SIGTOUT stopping is.

I'm not sure this is a complete explanation since I don't have "stty tostop"
set, meaning that there should be no inhibition to "vi" writing its output.
However, I have a strong feeling that the death of the process leader may
cause something significant and subtle within the tty routines that would
give an equivalent effect.

In any event, I have sent the problem on to my vendor (Pyramid) as a bug
and suggested that the cure may be to not create a new process group when
execing a program, but to continue to use the current one.  Would this
cause any problems?  Is this a reasonable solution?
-- 
-- Greg Noel, NCR Torrey Pines       Greg@ncr-tp.UUCP or Greg@nosc.ARPA