bin/107171: [patch] systat(1) doesn't die when it's xterm is killed while it's running

[Nate Eldredge]

The following reply was made to PR bin/107171; it has been noted by GNATS.

From: Nate Eldredge <nge at cs.hmc.edu>
To: bug-followup at FreeBSD.org, josh at tcbug.org, bde at zeta.org.au
Cc:  
Subject: Re: bin/107171: [patch] systat(1) doesn't die when it's xterm is
 killed while it's running
Date: Thu, 8 Mar 2007 19:09:22 -0800 (PST)

 Bruce Evans wrote:
 
 > However, EINTR is probably irrelevant for the current bug. systat
 > doesn't catch SIGHUP in order to clean up up unsafely like it does
 > for SIGINT, so any SIGHUP that gives EOF on the terminal would either:
 > - kill the process uncleanly, or
 > - not be delivered to the process because it is masked (no EINTR since
 > it is not caught), or
 > - not be delivered to the process because of job control stuff.
 
 I included the EINTR handling because systat does use SIGALRM.  In fact it 
 actually does all the display updating inside the SIGALRM handler (nice 
 huh?).  If we are sure that restarting syscalls are in effect (systat does 
 not explicitly select this behavior), then I agree that systat can die on 
 EINTR like any other error.  But if not then EINTR could legitimately 
 appear every time the alarm rings, and the correct behavior is to retry.
 
 > So systat just needs a simple check for EOF from getch() and the
 > remainly problem is that getch(), like getc(), unimproves on read()
 > by not having any way to distinguish the non-error of EOF from errors.
 
 Note getch() returns ERR, not EOF.  (In the current implementation they 
 are both equal to -1.)
 
 getc() is actually okay; when getc() returns EOF you can use ferror(f) and 
 feof(f) to decide if it was an error or end-of-file.  But yes, with 
 getch() you're stuck.  I guess because it's normally used on a terminal 
 device in raw mode, where you wouldn't normally receive an end-of-file 
 (since ^D wouldn't work).
 
 -- 
 Nate Eldredge
 nge at cs.hmc.edu