Re: <(...), >(...) and fds above 9

[Peter Stephenson <p.stephenson@samsung.com>]

On Mon, 2019-07-01 at 11:00 +0100, Stephane Chazelas wrote:
> /tmp$ zsh -c 'exec {fd}< a; zmodload zsh/system; sysopen -u fd2 /dev/fd/$fd; echo $fd $fd2; exec 7< a; ls -l /proc/self/fd; cat <(ls -l /proc/self/fd)'
> 12 13
> total 0
> lrwx------ 1 stephane stephane 64 Jul  1 10:52 0 -> /dev/pts/15
> lrwx------ 1 stephane stephane 64 Jul  1 10:52 1 -> /dev/pts/15
> lr-x------ 1 stephane stephane 64 Jul  1 10:52 12 -> /tmp/a
> lr-x------ 1 stephane stephane 64 Jul  1 10:52 13 -> /tmp/a
> lrwx------ 1 stephane stephane 64 Jul  1 10:52 2 -> /dev/pts/15
> lr-x------ 1 stephane stephane 64 Jul  1 10:52 3 -> /proc/464/fd
> lr-x------ 1 stephane stephane 64 Jul  1 10:52 7 -> /tmp/a
> total 0
> lrwx------ 1 stephane stephane 64 Jul  1 10:52 0 -> /dev/null
> l-wx------ 1 stephane stephane 64 Jul  1 10:52 1 -> pipe:[2044936]
> lrwx------ 1 stephane stephane 64 Jul  1 10:52 2 -> /dev/pts/15
> lr-x------ 1 stephane stephane 64 Jul  1 10:52 3 -> /proc/465/fd
> lr-x------ 1 stephane stephane 64 Jul  1 10:52 7 -> /tmp/a
> 
> It seems fds above 9 are closed in those forms of process substitutions. 
> 
> It doesn't happen for the =(...) form of process substitution.
> 
> Is that intentional?

I'd be surprised if there was any deliberate intention to make these different,
but there may be some detail I can't think of.

In general closing file descriptors from 10 up that don't have a good reason
to be open is handled by a call to closem() when forking.  There may
be a difference in the arguments used here, and "a good reason to be open"
is a matter of opinion and documentation rather than logical rigour.

pws