From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14175 invoked from network); 2 Oct 2001 10:24:42 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Oct 2001 10:24:42 -0000 Received: (qmail 4596 invoked by alias); 2 Oct 2001 10:24:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15921 Received: (qmail 4576 invoked from network); 2 Oct 2001 10:24:29 -0000 To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: PATCH: test for trap EXIT fix. In-reply-to: "Bart Schaefer"'s message of "Mon, 01 Oct 2001 16:01:58 -0000." <1011001160158.ZM23006@candle.brasslantern.com> Date: Tue, 02 Oct 2001 11:23:54 +0100 Message-ID: <19318.1002018234@csr.com> From: Peter Stephenson Bart Schaefer wrote: > On Oct 1, 1:01pm, Peter Stephenson wrote: > } > } The comment notes the following behaviour: > } > } fn() { > } ( trap 'print This is in the top-level function scope.' EXIT > } exit > } ) > } } > > Wait ... why is that trap at the top-level function scope? It's inside a > subshell. Shouldn't the subshell be its own scope? That's never happened before. We can introduce scopes for subshells, but it's probably quite a lot of work. > zsh% trap 'print PS1-level' EXIT; fn #1 > zsh% (trap 'print PS1-level' EXIT; fn) #2 > zsh% trap 'print PS1-level' EXIT; (exit) #3 > zsh% function TRAPEXIT { print PS1-level }; (exit) #4 > PS1-level > zsh% function TRAPEXIT { print PS1-level }; fn #5 > zsh% > > What's the excuse for the PS1-level trap not running any case but #4? The odd difference between #3 and #4 seems to be deliberate, weirdly enough. If you look at the top of entersubsh(), you will see traps are usually cleared (cl == 2 implies this is not a `real' subshell, for some definition of `not real' I haven't entirely worked out but which doesn't apply in this case), but are left when the trap is a function: if (cl != 2) for (sig = 0; sig < VSIGCOUNT; sig++) if (!(sigtrapped[sig] & ZSIG_FUNC)) unsettrap(sig); I can't imagine this is deliberately deliberate? It must have been deliberate in some accidental fashion. I think the behaviour of clearing existing traps on entering subshells is correct. But we probably need to handle the case of traps inside the subshell, when the subshell is in an arbitrary environment, better. Maybe there's a simple tweak to the code I introduced so this can be done without a full extra layer of scoping. -- Peter Stephenson Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. **********************************************************************