Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.bugs.4bsd,net.unix-wizards
Subject: Re: csh/jobs funniness
Message-ID: <3470@umcp-cs.UUCP>
Date: Thu, 21-Feb-85 23:23:27 EST
Article-I.D.: umcp-cs.3470
Posted: Thu Feb 21 23:23:27 1985
Date-Received: Tue, 26-Feb-85 06:18:45 EST
References: <1113@seismo.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 23
Xref: watmath net.bugs.4bsd:1404 net.unix-wizards:12126

> ...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@umcp-cs		ARPA:	chris@maryland