some problems with scope of fds in process substitution

[Stephane Chazelas]

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