RE: Trap and exit

["Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>]

> -----Original Message-----
> From: Peter Stephenson [mailto:pws@csr.com]
> 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
> 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.
>

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 ...
ough :-)

> 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.

-andrej