[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug when trapping exit from subshell

From: Chet Ramey
Subject: Re: Bug when trapping exit from subshell
Date: Mon, 19 May 2014 10:00:07 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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.


``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]