Xref: utzoo comp.mail.misc:2331 comp.unix.xenix:7416 comp.unix.wizards:17951 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!mcsun!ukc!warwick!cudcv From: cudcv@warwick.ac.uk (Rob McMahon) Newsgroups: comp.mail.misc,comp.unix.xenix,comp.unix.wizards Subject: Re: Checking for new mail (and killing bkgnd process on logout?) Message-ID: <196@titania.warwick.ac.uk> Date: 2 Sep 89 12:10:23 GMT References: <105@csnz.co.nz> <1989Aug26.200813.15629@twwells.com> <64@calcite.UUCP> <128@isgtec.UUCP> <4201@ncar.ucar.edu> Reply-To: cudcv@warwick.ac.uk (Rob McMahon) Organization: Computing Services, Warwick University, UK Lines: 28 In article <4201@ncar.ucar.edu> corbet@mead.UCAR.EDU (Jonathan Corbet) writes: >How about if you add a line like: > > signal (SIGHUP, SIG_DFL); > >toward the beginning of your main program? That will cause the program >to die when the parent process does... I've seen a couple of people say things like this now. It's not that csh sets its children to ignore SIGHUP, but rather that they never see it. Csh, at least on BSD systems with job control, puts each `job' into a process group of it's own, so that it can manipulate them (stop them as a complete job, move them into the foreground by setting the process group associated with the terminal the same as the job, put them into the background by doing the opposite). Since only processes in the process group associated with the terminal see keyboard generated signals, including SIGHUP, background processes never even have the signals delivered to them. So the only ways round this are to either have the shell kill the job before it goes away (by putting something in .logout), or by having the job check that its parent is still around occasionally, by checking the value of ppid(), or by kill(orig_ppid, 0)'ing. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England