From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9606 invoked by alias); 16 Feb 2016 23:38:29 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 38002 Received: (qmail 25494 invoked from network); 16 Feb 2016 23:38:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Message-ID: <56C3B2E7.1090806@inlv.org> Date: Wed, 17 Feb 2016 00:38:15 +0100 From: Martijn Dekker User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: zsh-workers@zsh.org CC: Peter Stephenson Subject: Re: [BUG] Sticky-sh POSIX_TRAPS are function-local References: <56C15DF1.8080405@inlv.org> <20160216095744.52cb8389@pwslap01u.europe.root.pri> In-Reply-To: <20160216095744.52cb8389@pwslap01u.europe.root.pri> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Peter Stephenson schreef op 16-02-16 om 10:57: > On Mon, 15 Feb 2016 06:11:13 +0100 > Martijn Dekker wrote: >> The POSIX_TRAPS option for the EXIT trap does not work if both of the >> following conditions apply: > > Oh, you mean the POSIXness of the trap is not sticky. It should be > marked as to be run at the end of the programme based on the emulation > when it was started. I don't think we've ever claimed it would be, > but it would be clearly be useful to change as the intention in > POSIX emulation is unambiguous. That's a much better way of putting it. > I think that's probably fixable with a bit of flaggery, but we'll > probably need to compromise and agree that if someone sets an EXIT trap > once the emulation is left, which therefore picks up non-POSIX behaviour > (if that's how the shell was started), it will wipe out the trap > completely. Otherwise we're in a weird and wonderful world of multiple > parallel EXIT traps. Presumably that's no big issue, since even in > POSIX mode a new EXIT trap wipes out the one you've just set. However, since POSIX traps are inherently global, the expectation that POSIX traps wipe out previous traps only applies to global traps. Could you make an exception for function-local traps? IMO, no one would expect a function-local trap to wipe out a global trap, whether or not the global trap was set in POSIX mode. For sticky-POSIX library functions to play nice with a native zsh script, it would be necessary for native function-local traps to still work as expected. In other words, in my view, the following ought to work: #! Src/zsh -f emulate sh -c 'trap "echo POSIX exit trap triggered" EXIT' fn() { trap "echo native zsh function-local exit trap triggered" EXIT echo entering native zsh function } fn Expected output: entering program entering native zsh function native zsh function-local exit trap triggered exiting program POSIX exit trap triggered With your current patch, the function-local trap wipes out the global POSIX exit trap, so the last line of expected output doesn't appear. Thanks, - M.