Xref: utzoo comp.unix.questions:28625 comp.unix.internals:2026
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!rex!uflorida!gatech!udel!princeton!tan.Princeton.EDU!pfalstad
From: pfalstad@tan.Princeton.EDU (Paul Falstad)
Newsgroups: comp.unix.questions,comp.unix.internals
Subject: Re: SIGCONT occurs after a SIGTERM
Message-ID: <6176@idunno.Princeton.EDU>
Date: 12 Feb 91 01:48:47 GMT
References: <7103@fs1.cam.nist.gov>
Sender: news@idunno.Princeton.EDU
Followup-To: comp.unix.questions
Organization: The Royal Society For Putting Things On Top Of Other Things
Lines: 26

coleman@cam.nist.gov (Sean Sheridan Coleman X5672) wrote:
>Please explain to me why a SIGCONT is sent to a process after
>SIGTERM is sent to my process. It doesn't compute because TERM
>means to terminate the the process. I catch SIGCONT because I 

This is caused by the following code in csh's sh.proc.c:

         if (signum == SIGTERM || signum == SIGHUP)
            (void) killpg((pid_t) pp->p_jobid, SIGCONT);

There is a good reason for this.  If you kill a stopped process, it
will not die until you send it a SIGCONT (unless you use SIGKILL).
It is counterintuitive for a process not to die when you type
"kill <process>", so somebody just threw in these two lines to have it
send a SIGCONT as well.  For the shell's kill code to not check to see if the
process is actually stopped before sending it a SIGCONT is just sloppy;
also singling out only SIGTERM and SIGHUP for this special treatment is a real
hack IMHO (unless I'm missing something).  Use /bin/kill <pid> which does
not do this.

--
Paul Falstad, pfalstad@phoenix.princeton.edu | 10 PRINT "PRINCETON CS"
[Your blood pressure just went up.]          | 20 GOTO 10
Princeton University would like to apologize to everyone for this article.
            "It seems inappropriate to use comp.unix.wizards
             as an AI interface to TFM."  - Tom Christiansen