Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tekcrl.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!tektronix!tekcrl!terryl
From: terryl@tekcrl.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Bug in csh? (exec v. job control)
Message-ID: <108@tekcrl.UUCP>
Date: Fri, 26-Apr-85 03:13:53 EDT
Article-I.D.: tekcrl.108
Posted: Fri Apr 26 03:13:53 1985
Date-Received: Sun, 28-Apr-85 06:40:59 EDT
References: <175@ncr-tp.UUCP>
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.

     You're right (the > person). What is happening is that the exec'ed
process has died, and vi waited on the process and found out it has died
(for whatever reason). Now, what vi does is try to set the terminal modes
back to what it thinks it should be, but because its process group does not
match the current controlling process group of the terminal, vi gets sent a
SIGTTOU, just as > reported.