[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "trap" output from "if" statement redirected wrongly
From: |
Frank Heckenbach |
Subject: |
Re: "trap" output from "if" statement redirected wrongly |
Date: |
Wed, 13 Apr 2022 17:15:40 +0200 |
> On Wed, Apr 13, 2022 at 7:59 AM Frank Heckenbach
> <f.heckenbach@fh-soft.de> wrote:
> > This script writes "foo" to bar rather than stdout as I'd expect.
> >
> > It's triggered by the "if" statement (which doesn't even cause
> > running in a subshell, so it's not that).
> >
> > #!/bin/bash
> > set -e
> > trap 'echo foo' 0
> > #false > bar # "foo" written to stdout correctly
> > if true; then false; else false; fi > bar # "foo" written to bar
>
> I don't believe this is a bug, though Chet is welcome to chime in
> with an authoritative answer. The script exits after the else clause
> because false returns 1 and errexit is set. At this point in the program
> stdout has been redirect to the file bar, so when the trap echos to
> stdout its content goes to bar as well. I don't see anything in the
> docs about traps resetting their output file descriptors before they
> are ran.
I don't see anything to the contrary either. Syntactically, the
redirection applies to the main statement, not the trap. When and
how redirections are set up and reset is an implementation detail.
Moreover, I don't see anything that would make a difference between
the "if" statement and the plain one, so if the behaviour you
describe is correct, the bug is that the non-"if" statement actually
writes to stdout. :P
> To work around this you need to save the original stdout file
> descriptor.
I know how to work around. But that makes me wonder. What is
actually required to use a trap-statement safely (meaning, in a
non-surprising way)? I know (for an EXIT trap) to save "$?" and
"rethrow" it, now it seems one needs to save all FDs it might use
(STDOUT, STDERR, maybe STDIN or other FDs one might redirect
somewhere). What else is required? Is this documented anywhere?