Re: Trap and exit

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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