Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: TRAPEXIT question
- X-seq: zsh-workers 7354
- From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx (Zsh list)
- Subject: Re: TRAPEXIT question
- Date: Wed, 04 Aug 1999 09:47:31 +0200
- In-reply-to: ""Bart Schaefer""'s message of "Wed, 04 Aug 1999 04:40:26 DFT." <990804044026.ZM12690@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
"Bart Schaefer" wrote:
> This has an interesting side-effect in the case of the EXIT trap. If you
> use the `TRAPEXIT() { ... }' function form, then other traps set within the
> trap itself have the context of the TRAPEXIT function; but if you use the
> `trap "..." EXIT' form, traps set within the trap have as their context a
> function that has already exited -- and as a consequence they get set in
> the next context up, which can even be the top-level shell.
>
> (I don't know if any other shell behaves this way; I know bash does *not*.
> The new LOCAL_TRAPS option in 3.1.6 doesn't appear to affect it.)
ksh works this way, as far as the trap builtin is concerned, which is why
zsh does. bash doesn't seem to regard EXIT traps as applying to functions
at all. Neither of them have TRAP functions, which were presumably
introduced to avoid the messy quoting syntax, although as you pointed out
you can have the real function defined somewhere else (but then you still
lose the effect of being in the surrounding context). In the early days
zsh called them both with a separate function environment, and this is
different from any other shell; only the trap builtin was fixed, however,
since if you define a function trap it's natural that it should have a
function environment.
--
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx> Tel: +39 050 844536
WWW: http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy
Messages sorted by:
Reverse Date,
Date,
Thread,
Author