greg@ncr-tp.UUCP (Greg Noel) (04/04/85)
There seems to be a bug in the way the C shell's exec function interacts with job control. The quickest way to show it: - Run the C shell and make sure that the SHELL environment variable is set to /bin/csh. - type "vi garbage-file" to get a program that will create a shell. - type ":sh" to get a shell. The C shell should prompt you. - type "exec echo foo" -- actually, exec any program. In theory, this should run the specified program and then return to the editor. Now tell me, why was the editor stopped with a "tty output"? -- -- Greg Noel, NCR Torrey Pines Greg@ncr-tp.UUCP or Greg@nosc.ARPA
anton@ucbvax.ARPA (Jeff Anton) (04/06/85)
In article <160@ncr-tp.UUCP> greg@ncr-tp.UUCP (Greg Noel) writes: >There seems to be a bug in the way the C shell's exec function interacts >with job control. The quickest way to show it: > - Run the C shell and make sure that the SHELL environment variable > is set to /bin/csh. > - type "vi garbage-file" to get a program that will create a shell. > - type ":sh" to get a shell. The C shell should prompt you. > - type "exec echo foo" -- actually, exec any program. In theory, > this should run the specified program and then return to the editor. > >Now tell me, why was the editor stopped with a "tty output"? >-- >-- Greg Noel, NCR Torrey Pines Greg@ncr-tp.UUCP or Greg@nosc.ARPA 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 from the forked process dying and tries to print something. The vi's process group now does not match the terminals so the system sends the process group a SIGTOUT stopping is. The csh that forked vi finds that the vi has stoped and then gives you control to fg it. The whole process group, job control stuff is very messy. If you had a /bin/sh, ran vi, changed vi to call a csh, did the shell escape and exec command your terminal would be hung since vi's process group would include your /bin/sh. Very nasty. Ever wonder why 'suspend' on a login shell prints: Can't suspend a login shell. (yet) -- C knows no bounds. Jeff Anton U.C.Berkeley ucbvax!anton anton@berkeley.ARPA
greg@ncr-tp.UUCP (Greg Noel) (04/24/85)
> 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
chris@umcp-cs.UUCP (Chris Torek) (04/26/85)
> > [...] The vi wakes up from the forked process' dying and tries > > to print something. Vi's process group now does not match the > > terminal's, so the system sends the process group a SIGTOUT [sic] > > stopping it. > 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. The first explanation was mostly correct. Vi is not just trying to print something, it's trying to set the terminal modes (ioctl TIOCSETN, actually); "stty tostop" affects programs that are attempting to write, but the check for ioctl is more strict: SIGTTOU will be sent if the process group doesn't match, regardless of (tp->t_mode & TOSTOP). (I.e., it's a bug in csh, or in the way process groups are defined, if you prefer.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
terryl@tekcrl.UUCP (04/26/85)
>> 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.