csh/jobs funniness

[Chris Torek]

> ...if you have a job running in the background, jobs says running
> and ps will give a stat of R indicating runnable. If you send ...  a
> signal 17 or 18 (STOP,TSTP) using kill, jobs will indicate the process
> has stopped and ps will indicate T for stopped. ...  however if you
> restart the job using using kill -19 pid (or -CONT) the process does
> restart, ps will give a STAT of R, but jobs will indicate still
> stopped.

It's a ``feature''.  Ps reaches into the kernel and pulls out the per-
process data, thus gets the right answer.  Jobs relies on the C shell's
knowledge of what's going on.  Since ``kill'' is a built-in command,
the C shell *could* notice kill -CONT's and update its own information,
but you could still defeat it by running /bin/kill (or sending the signal
from another terminal).

When a process stops, its parent can find out by using the ``wait3''
system call.  However, there is no information given about restarted
processes.  Csh's ``bg'' and ``fg'' commands update the job status
when asked to continue a stopped job, but its ``kill'' command doesn't.
-- 
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 at umcp-cs		ARPA:	chris at maryland