From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28268 invoked from network); 17 May 2005 15:42:32 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 17 May 2005 15:42:32 -0000 Received: (qmail 49231 invoked from network); 17 May 2005 15:42:26 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 May 2005 15:42:26 -0000 Received: (qmail 13109 invoked by alias); 17 May 2005 15:42:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21265 Received: (qmail 13096 invoked from network); 17 May 2005 15:42:22 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 17 May 2005 15:42:22 -0000 Received: (qmail 48695 invoked from network); 17 May 2005 15:42:22 -0000 Received: from vms044pub.verizon.net (206.46.252.44) by a.mx.sunsite.dk with SMTP; 17 May 2005 15:42:12 -0000 Received: from candle.brasslantern.com ([4.11.1.68]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGN005PT4YAQB44@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Tue, 17 May 2005 10:42:11 -0500 (CDT) Received: from candle.brasslantern.com (IDENT:schaefer@localhost [127.0.0.1]) by candle.brasslantern.com (8.12.11/8.12.11) with ESMTP id j4HFgA2b027506 for ; Tue, 17 May 2005 08:42:10 -0700 Received: (from schaefer@localhost) by candle.brasslantern.com (8.12.11/8.12.11/Submit) id j4HFg9b2027505 for zsh-workers@sunsite.dk; Tue, 17 May 2005 08:42:09 -0700 Date: Tue, 17 May 2005 15:42:09 +0000 From: Bart Schaefer Subject: Re: Z shell signal handling In-reply-to: <20050517081513.GA93407@quark.hightek.org> To: zsh-workers@sunsite.dk Message-id: <1050517154209.ZM27504@candle.brasslantern.com> MIME-version: 1.0 X-Mailer: Z-Mail (5.0.0 30July97) Content-type: text/plain; charset=us-ascii References: <20050426030308.GA21501@quark.hightek.org> <200504261834.j3QIYHSa018951@news01.csr.com> <1050427053638.ZM28743@candle.brasslantern.com> <200504270954.j3R9sujP029445@news01.csr.com> <20050507171938.GA51740@quark.hightek.org> <5415.1115631148@csr.com> <20050510184600.GA67763@quark.hightek.org> <200505131127.j4DBR0Yt014380@news01.csr.com> <20050514043338.GA82132@quark.hightek.org> <200505161046.j4GAknfO018203@news01.csr.com> <20050517081513.GA93407@quark.hightek.org> Comments: In reply to Vincent Stemen "Re: Z shell signal handling" (May 17, 3:15am) X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Hits: -2.6 On May 17, 3:15am, Vincent Stemen wrote: } Subject: Re: Z shell signal handling } } There are a couple potential problems I can see with the sh approach, } that I am guessing zsh and bash were trying to fix. The biggest problem is that C library routines like malloc() are not re-entrant, and are heavily used by the shell. The issue is not with race conditions, etc., at the level of shell function execution, but deep within the shell implementation, possibly in places that are not within the shell implementer's control. When PWS speaks about whether it's "safe" to enable signals, he means that if it's NOT safe, the shell is going to corrupt memory, possibly crash, or even open holes in system security. Behaving the way that the script programmer expects is secondary to these considerations.