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 BAA03954 for <mason@primenet.com.au>; Thu, 14 Nov 1996 01:20:50 +1100 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id JAA29797; Wed, 13 Nov 1996 09:07:54 -0500 (EST)
Resent-Date: Wed, 13 Nov 1996 09:07:54 -0500 (EST)
From: Zefram <zefram@dcs.warwick.ac.uk>
Message-Id: <11873.199611131406@stone.dcs.warwick.ac.uk>
Subject: signal weirdness
To: zsh-workers@math.gatech.edu (Z Shell workers mailing list)
Date: Wed, 13 Nov 1996 14:06:49 +0000 (GMT)
X-Loop: zefram@dcs.warwick.ac.uk
X-Stardate: [-31]8417.94
X-US-Congress: Moronic fuckers
Content-Type: text
Resent-Message-ID: <"F0jqy3.0.SH7.vOTYo"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/2388
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

I got these results on Solaris 2.5.1 and SunOS 4.1.4, not tested
anywhere else.

Create a program called "segv", from this source or something equivalent:

main() { *(volatile char *)0 = 1; }

(I.e., the program will die with a SIGSEGV.)

Run the script:

trap 'echo SIGSEGV' SEGV
foo=$(segv)
echo finished
exit 0

When the segv program terminates, zsh acts as if it had received a
SIGSEGV (it executes the trap), despite the fact that it was its child
process that received it.  This doesn't happen if the signal is not
trapped.

The same happens if the command is run directly, rather than being
within $().

I'm not looking into this at the moment; I'm not familiar with the
signal code, and I have more urgent things to do.  I hope someone can
diagnose this.

-zefram