Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Trap and exit
- X-seq: zsh-users 3488
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-users@xxxxxxxxxxxxxx (Zsh users list)
- Subject: Re: Trap and exit
- Date: Fri, 27 Oct 2000 14:19:34 +0100
- In-reply-to: "Your message of Fri, 27 Oct 2000 15:37:48 +0400." <000001c0400a$54f99fb0$21c9ca95@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxxxxxx; run by ezmlm
> It looks like a bug in Zsh.
>
> =============
> The environment in which the shell executes a trap on EXIT will be identical
> to the environment immediately after the last command executed before the tra
> p
> on EXIT was taken.
>
> The exit status will be n, if specified. Otherwise, the value will be the exi
> t
> value of the last command executed, or zero if no command was executed. When
> exit is executed in a trap action, the last command is considered to be the
> command that executed immediately preceding the trap action.
>From this it looks like the status of the trap is the exit value of the
exit command --- not of the function. I'm not sure that's even defined.
If the exit, unlike the function, completed successfully, you could argue
that the status should be 0. However, that's not what we're doing.
% cat foo
trap 'echo trap: $?' 0
false
exit 59
% zsh ./foo
trap: 1
But then, you could argue that the false was the last command before the
script exited, and is hence the one referred to in this case --- given that
this is exactly what happens with an implicit exit by falling off the end.
To summarise: bleah.
I'm getting the same result as zsh with sh on SunOS 5.6 and the bundled ksh
M-11/16/88i, by the way (except false returns 255).
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070
Messages sorted by:
Reverse Date,
Date,
Thread,
Author