20 Temmuz 2020 Pazartesi tarihinde Rusty Bird <rustyb...@net-c.com> yazdı:
> Oğuz:
> > > For context - I'm filtering a program's stdout and stderr
> > > (separately), requiring successful exit statuses for the program and
> > > both filters:
> > >
> > > set -u -o pipefail
> > > { program 2> >(stderr_filter >&2) && wait $!; } |
> stdout_filter &&
> > > ...
>
> > Not sure if process substitution is really necessary here,
> >
> > set -u -o pipefail
> > { program 2>&3 | stdout_filter; } 3>&1 | stderr_filter && ...
> >
> > does the same thing.
>
> That one filters program's stdout twice - first through stdout_filter
> and then through stderr_filter - with program's stdout and stderr both
> finally arriving at stdout. But tweaked like this, it seems to cover
> all the bases:
>
> set -u -o pipefail
> {
> program 2>&1 >&"$out" {out}>&- |
> stderr_filter >&2 {out}>&-
> } {out}>&1 | stdout_filter
>
>
Yes, I thought stdout_filter and stderr_filter didn't produce output, silly
me. `>&"$out" is very ugly though, it'd be nice if `{var}' thing worked at
the RHS of redirection operator, like `>&{var}`, which, on bash 5.0.11,
ignores `&' -another bug?- and redirects stdout to a file named `{var}'.
> And it even waits for stderr_filter if program failed. My original
> snippet neglected that case, otherwise it would have looked more like
>
> set -u -o pipefail
> (
> trap 'wait $! || exit $?' EXIT
> command program 2> >(stderr_filter >&2)
> ) | stdout_filter
>
> which isn't exactly pretty either, even if the bug(?) requiring
> 'command' is fixed.
>
> Rusty
>
--
Oğuz
