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

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

2019-07-01 17:52:53 +0100, Peter Stephenson:
> On Mon, 2019-07-01 at 17:22 +0100, Stephane Chazelas wrote:
> > 2019-07-01 16:28:28 +0100, Peter Stephenson:
> > [...]
> > > 
> > > Looks like =(...) doesn't call closem() at all when
> > > forking, hence the difference in behaviour.  So
> > > =(...) is the odd one out.
> > [...]
> > 
> > But is there a good reason why we should close those fds?
> 
> The shell has no idea whether you're happy to have lingering file
> descriptors when executing any old external software, so has to play
> safe in general.  It assumes you know what you're doing with file
> descriptors 0 to 7 and certain other types, and that others are
> dangerous.
[...]

Thanks, but I don't follow.

In

exec 7< file

I have file open on fd 7 which I can use anywhere, after fork(),
after execve().

With

exec {fd}< file

It's the same except the fd is assigned dynamically but I don't
see how they should be treated differently. Presumably, if I'm
doing that, I want to be able to use that fd later on, most
probably in some command which unless the command happens to be
a builtin involves both a fork() and execve().

In

$ ls -l /proc/self/fd
total 0
lrwx------ 1 chazelas chazelas 64 Jul  1 20:47 0 -> /dev/pts/1
lrwx------ 1 chazelas chazelas 64 Jul  1 20:47 1 -> /dev/pts/1
lr-x------ 1 chazelas chazelas 64 Jul  1 20:47 12 -> /home/chazelas/a
lrwx------ 1 chazelas chazelas 64 Jul  1 20:47 2 -> /dev/pts/1
lr-x------ 1 chazelas chazelas 64 Jul  1 20:47 3 -> /proc/26481/fd

There is both a fork() and a execve() and that fd 12 survived.

It survives in

(ls -l /proc/self/fd)
echo "$(ls -l /proc/self/fd)"
ls -l /proc/self/fd | cat
cat =(ls -l /proc/self/fd)

Not in

ls /proc/self/fd &
coproc ls /proc/self/fd
cat <(ls /proc/self/fd)

It looks like the key is *background* here, and it sounds like
the reason is not so much about what the user expects but
possibly some implementation limitation/consideration, maybe
something to do with job control and/or the fact that some of the
fds above 9 are not user ones but some created internally by zsh
for its own internal soup?

Is it documented anywhere that fds above 9 are closed for all
commands started asynchronously?

-- 
Stephane