csh bug?

[joe at cvl.UUCP]

Rusty at sdcarl wanted to know of the behaviour of the script

	#! /bin/sh
	sleep 9600 &
	echo sleeping...
	sleep 3600

was wrong, because it showed both sleep processes stopped after being
^Z'ed (started from a csh, of course).  The answer to the question is
no, there is nothing wrong about this behaviour, even when the first
line specifies /bin/csh instead of /bin/sh.  I've seen a number of
people make a similar subtle assumption about '&'.  The problem is that
people who've been exposed to the csh first do not realize the csh
explicitly manipulates the process group of every subprocess.  The two
most common mistakes are (1) to assume that sh does the same thing, and
(2) to assume that NONINTERACTIVE instances of csh still manipulate
process groups.  A stop signal from the terminal is dispatched to all
members of the terminal's current process group.  For the regular
shell, and noninteractive c-shells, this means all of the shell's
children are in the same process group as the shell itself, and all
will receive the signal (if the shell itself is in the terminal's pgrp,
which it will be if started from sh or an interactive csh).

The reason I'm familiar with all this is that we have some users
running the standard shell (for historical reasons).  Unfortunately,
they'd been told by well-meaning csh users that `nohup' was not
necessary under Berkeley UNIX when processes were started with '&'.  Of
course, the moment they logged out their background processes got a
SIGHUP, since they were in the terminal's process group.

It's trivial to write a command I call `newpg', which simply executes
its arguments as a command in a new process group.  Hence, 'newpg
command args ... & ' behaves under sh and noninteractive csh like the
corresponding 'command args ... & ' does in an interactive csh.

joe at cvl.uucp
 seismo!
   mcnc!rlgvax!cvl!joe
   we13!