Re: 'foo > >(bar)' doesn't set $! for external foo not invoked via 'command'

[Oğuz]

20 Temmuz 2020 Pazartesi tarihinde Rusty Bird <rustybird@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