On 5/18/14, 12:56 PM, Mark Ferrell wrote:
> I believe that if you actually execute the script as intended you will
> find that your reading of the code is incorrect. Really though,
> redirection should not be the problem since:
>
> 1. Redirection of the output of one command does not change the
> redirection of the script as a whole, and so it should never change
> redirection of the command invoked by the handler. Changing
> redirection of the script as a whole via 'exec' sure .. but not for a
> single command.
It depends on the context in which the exit trap is executed. The `set -e'
causes the shell to exit as soon as a command fails, and the exit trap is
run while the shell is exiting, in the context of the failed command. In
this case, that's `main', which has its stdout and stderr redirected. If
you remove the set -e, you get different behavior.
The exit_handler function is always called: if you add something like
`touch exit_handler' you'll see that that file is always created. It's
not a question of whether or not the trap is executed, it's a question
of whether or not bash unwinds the redirections on its way out of the
shell. When bash executes a builtin or shell function in a subshell, or
bails because a command is not found, it doesn't bother to do that.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
