On Mon, May 19, 2014 at 10:45 AM, Greg Wooledge <wool...@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;"
