From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-request@euclid.skiles.gatech.edu Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.6/8.7.3) with ESMTP id FAA05454 for ; Thu, 14 Nov 1996 05:09:29 +1100 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id NAA05631; Wed, 13 Nov 1996 13:04:03 -0500 (EST) Resent-Date: Wed, 13 Nov 1996 13:04:03 -0500 (EST) From: Zefram Message-Id: <26092.199611131803@stone.dcs.warwick.ac.uk> Subject: Re: signal weirdness To: schaefer@nbn.com Date: Wed, 13 Nov 1996 18:03:01 +0000 (GMT) Cc: zefram@dcs.warwick.ac.uk, zsh-workers@math.gatech.edu In-Reply-To: <961113094120.ZM29104@candle.brasslantern.com> from "Bart Schaefer" at Nov 13, 96 09:41:19 am X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]8418.76 X-US-Congress: Moronic fuckers Content-Type: text Resent-Message-ID: <"jssLK.0.vN1.JsWYo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2396 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > /* If the foreground job got a signal, pretend we got it, too. */ Oh. >This code is intended to handle (among other things) the case where the >user types the interrupt character when a foreground job is executing, >thereby causing zsh to behave the same as if interrupt were typed at a >bare prompt. Similarly, if the user typed the quit character, or if >the foreground job got a HUP because the tty line dropped, we want zsh >to notice and behave as if it got the signal as well. But (except for >INT and QUIT), the signals are only interesting if they're trapped, as >zsh normally ignores the rest. I don't see the problem with just ignoring the situation, in the case of key-generated interrupts. If the user wants to kill a program *and* have the shell process a SIGINT handler, e can press ^C twice. HUP is the only one that we really need to handle specially. >Anyway, the code is more general than it needs to be -- there is only >a subset of signals (HUP, INT, QUIT, TSTP, ...) that really need to be >handled this way. On the other hand, there's no way to make a good >comprehensive cross-platform list of all the signals that should be so >treated, which is why it's as general as it is. Shouldn't it be only INT, QUIT and HUP? I can't see any others that could justifiably be treated this way. > It might be possible >to come up with a list of signals that we know should *not* be treated >this way (BUS, FPE, SEGV, others?) and explicitly omit them, if this >is really annoying for some reason. It is very annoying. It seems like the shell is going out of its way to cause inconvenience: without that code it would be easy to distinguish between an external program crashing and the shell crashing. What does POSIX say about all of this? -zefram