Bug in csh? (exec v. job control)

[Jeff Anton]

In article <160 at ncr-tp.UUCP> greg at 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 at ncr-tp.UUCP or Greg at 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 at berkeley.ARPA