FYI, as seen at https://unix.stackexchange.com/a/408171, there are still a few "problems" with process substitution, where some fds are closed where they probably shouldn't:
> Note that even with the latest (4.4.12 as of writing) version, bash still has > a few bugs here like: > > $ bash -c 'eval cat <(echo test)' > test # OK but: > $ bash -c 'eval "echo foo;cat" <(echo test)' > foo > cat: /dev/fd/63: No such file or directory > $ bash -c 'eval f=<(echo test) "; cat \$f"' > cat: /dev/fd/63: No such file or directory > > and some still triggered by pipes like: > > $ cat file > echo "$1" > cat "$1" > $ bash -c 'source ./file <(echo test)' > /dev/fd/63 > test # OK but: > $ cat file2 > echo "$1" | wc -c > cat "$1" > $ bash -c 'source ./file2 <(echo test)' > 11 > cat: /dev/fd/63: No such file or directory Also, there's a lot of problems reported at unix.stackexchange.com at least that are caused by bash not waiting for the processes started by process substitutions, especially the >(...) form. It would be more useful IMO if bash waited for them like zsh does (under some conditions) or ksh93 can be told do. More details at: https://unix.stackexchange.com/a/403788 -- Stephane
