[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Fwd: Bug when trapping exit from subshell
From:       Mark Ferrell <major () homeonderanged ! org>
Date:       2014-05-19 23:03:01
Message-ID: CANR0-ahiq_FocmnvWmWYW2EiBc=kbQGuHs53H_TBQVhoo=HKNw () mail ! gmail ! com
[Download RAW message or body]

On Mon, May 19, 2014 at 10:45 AM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Mon, May 19, 2014 at 10:39:59AM -0700, Mark Ferrell wrote:
>> I'm sorry, but the lack of consistency still sounds like it is a bug
>> in bash.  The behaviour I would expect is functionally equivalent to
>> 'do_cmd > /dev/null 2>&1 || err_handler'.  Further more, this IS the
>> behaviour seen if the command being executed is NOT a
>> builtin/function.
>
> I won't take sides on that particular issue, but as a workaround, could
> you use something like this?
>
> exec 8>&1 9>&2     # Save original stdout & stderr for use in error handler
> err() { echo "${1:-Error}" >&9; }

Yah, I may have to do something along those lines to get around this
for backwards compatibility with what can only be deemed as a bash
bug.

POSIX states the following in regards to trap:

"The environment in which the shell executes a trap on EXIT shall be
identical to the environment immediately AFTER the last command
executed before the trap on EXIT was taken."

I think this is pretty clear.  error_handler() should not have its
output redirected as it should be handled as if "following" the
command which triggered the exit.  "cmd > /dev/null 2>&1 ;
error_handler;"


[prev in list] [next in list] [prev in thread] [next in thread]