Zsh Mailing List Archive
Messages sorted by:
RE: Trap and exit
- X-seq: zsh-users 3490
- From: "Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>
- To: "Zsh users list" <zsh-users@xxxxxxxxxxxxxx>
- Subject: RE: Trap and exit
- Date: Fri, 27 Oct 2000 17:39:50 +0400
- Importance: Normal
- In-reply-to: <0G330024BBOLZ9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxxxxxx; run by ezmlm
> -----Original Message-----
> From: Peter Stephenson [mailto:pws@xxxxxxx]
> Sent: Friday, October 27, 2000 5:20 PM
> To: Zsh users list
> Subject: Re: Trap and exit
> > 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.
The `exit value of exit command' is defined in second sentence that was taken
from the description of exit command. This is `n, if specified'. That is, exit
status of command `exit 59' is 59. Actually, this makes sense - it sets $? to
59 and exits shell, leaving it with `exit status of last command'.
Of course, Unix standards are known to use the most obscure wording possible.
> % cat foo
> trap 'echo trap: $?' 0
> 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.
The last command executed was `exit' not `false'. So, the above is a bug in
any case - exit status is either 0 or 59 (depending on exit status of exit ...
> To summarise: bleah.
Well, it adds to functionality in any case; and youor example IMHO counts as
bug. sh and ksh scripts do not expect this anyway and won't be broken. But
there are more chances that bash/ash scripts will run properly.
Messages sorted by: