Trap and exit

Trap and exit

[Akim Demaille]

I am not claiming this is a bug in Zsh, but I confess I prefer the
behavior from Bash and Ash.

/tmp % cat foo.sh                                                nostromo 12:42
#! /bin/sh
trap 'echo trap: $?' 0
exit 59
/tmp % ash ./foo.sh                                              nostromo 12:42
trap: 59
/tmp % bash ./foo.sh                                            nostromo Err 59
trap: 59
/tmp % zsh ./foo.sh                                             nostromo Err 59
trap: 0
/tmp %                                                          nostromo Err 59

What do you think?

RE: Trap and exit

[Andrej Borsenkow]

>
> I am not claiming this is a bug in Zsh, but I confess I prefer the
> behavior from Bash and Ash.
>
> /tmp % cat foo.sh
> nostromo 12:42
> #! /bin/sh
> trap 'echo trap: $?' 0
> exit 59
> /tmp % ash ./foo.sh
> nostromo 12:42
> trap: 59
> /tmp % bash ./foo.sh
> nostromo Err 59
> trap: 59
> /tmp % zsh ./foo.sh
> nostromo Err 59
> trap: 0
> /tmp %
> nostromo Err 59
>
> What do you think?
>

It looks like a bug in Zsh. Quoting Unix 98:

=============
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 trap
on EXIT was taken.
=============

In this case last command was 'exit 59'. What is exit code of _this_ command?
Quoting Unix 98 again:

=============
The exit status will be n, if specified. Otherwise, the value will be the exit
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.
=============

So, on entry into TRAPEXIT function $? is expected to be the same as exit
status. At least, it is how I understand two statements above.

cheers

-andrej

RE: Trap and exit

[Andrej Borsenkow]

> > #! /bin/sh
> > trap 'echo trap: $?' 0
> > exit 59
> > /tmp % ash ./foo.sh
> > trap: 59
>
> It looks like a bug in Zsh. Quoting Unix 98:
>

OTOH both sh and ksh here behave the same as Zsh. Unless there are
compatibility reasons, I still prefer sh/bash.

-andrej

Re: Trap and exit

[Akim Demaille]

>>>>> "Andrej" == Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> writes:

Andrej> Quoting Unix 98:

is this document publicly available?

Re: Trap and exit

[Akim Demaille]

| OTOH both sh and ksh here behave the same as Zsh. Unless there are
| compatibility reasons, I still prefer sh/bash.

What implementation are you referring to?  What do you call `ksh' and
`sh' here?

RE: Trap and exit

[Andrej Borsenkow]

> 
> 
> | OTOH both sh and ksh here behave the same as Zsh. Unless there are
> | compatibility reasons, I still prefer sh/bash.
> 
> What implementation are you referring to?  What do you call `ksh' and
> `sh' here?
> 

ReliantUNIX 5.44 :-) (known as SINIX before)  ksh 88: Version 11/16/88i

And I meant ash/bash, of course.

-andrej

RE: Trap and exit

[Andrej Borsenkow]

>
> >>>>> "Andrej" == Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> writes:
>
> Andrej> Quoting Unix 98:
>
> is this document publicly available?
>
>

<http://www.opengroup.org/onlinepubs/007908799/>

This refers to Single Unix Specification V2, but for all I know, it _is_ Unix
98.

-andrej

Re: Trap and exit

[Peter Stephenson]

> 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@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Trap and exit

[Akim Demaille]

>>>>> "Peter" == Peter Stephenson <pws@csr.com> writes:

Peter> But then, you could argue that the false was the last command
Peter> before the script exited, and is hence the one referred to in
Peter> this case --- given that this is exactly what happens with an
Peter> implicit exit by falling off the end.

Whatever you decide, please remain compatible with the workaround used
in Autoconf: using `(exit 77); exit 77' instead of `exit 77' must have
the desired property: the trap is triggered, and it receives $? = 77.

RE: Trap and exit

[Andrej Borsenkow]

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

Re: Trap and exit

[Bart Schaefer]

On Oct 27,  3:37pm, Andrej Borsenkow wrote:
}
} > /tmp % cat foo.sh
} > nostromo 12:42
} > #! /bin/sh
} > trap 'echo trap: $?' 0
} > exit 59
} > /tmp % zsh ./foo.sh
} > nostromo Err 59
} > trap: 0
} 
} It looks like a bug in Zsh. Quoting Unix 98:
} 
} =============
} 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 trap
} on EXIT was taken.
} =============
} 
} In this case last command was 'exit 59'.

Here's where we get into a matter of semantics; zsh doesn't consider the
"exit" command to have finished executing until the shell has actually
exited, so "last command BEFORE the trap" was in this case the trap
command itself.  The trap on exit is taken *during* the exit command,
not *after* it.

} What is exit code of _this_ command?

What does "_this_" mean?  Peter seems to have taken it to mean "the entire
script" whereas you seem to have meant "the `exit' command itself."

} Quoting Unix 98 again:
} 
} =============
} The exit status will be n, if specified. Otherwise, the value will be the exit
} 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.
} =============

This appears to mean that:

	#!/bin/zsh
	trap 'true; exit' 0
	false

*should* always give $? = 1, because the last command executed before *the
trap* will have been "false", whereas zsh in this case *does* give $? = 0,
because the last command before the explicit "exit" is "true".

That one could be quite annoying to fix.

While we're on the topic:

zsh% TRAPEXIT() { echo trap called }
zsh% (true)
zsh% (true;exit)
trap called
zsh%

Is the exit trap supposed to be triggered on a subshell exit?  Is an
explicit call to "exit" supposed to make this difference?

Note also that this only happens with TRAPEXIT, and not with `trap ... 0'.
Is *that* intentional?

On Oct 27,  2:19pm, Peter Stephenson wrote:
}
} 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.

I'm not even sure how to parse your sentence.

On Oct 27,  3:28pm, Akim Demaille wrote:
}
} Whatever you decide, please remain compatible with the workaround used
} in Autoconf: using `(exit 77); exit 77' instead of `exit 77' must have
} the desired property: the trap is triggered, and it receives $? = 77.

That's true now, and shouldn't become a problem.

On Oct 27,  5:39pm, Andrej Borsenkow wrote:
}
} > 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'.

No, that's my point made above.  The exit command has not finished executing
until the shell actually exits, at which point it's too late to consider it
to have executed before the trap.

} > To summarise: bleah.
} 
} Well, it adds to functionality in any case;

I don't follow this, I'm afraid.  Which is "it", and what does it add?

} and your example IMHO counts as bug.

I still think there's room for disagreement, unless you can show me where
the spec says that the exit command is considered to have finished before
the exit trap is called, even though the shell hasn't exited yet.

My example, however, does look like an actual bug, or at least an actual
nonconformance to that spec, which is not exactly the same thing.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net