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

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

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.

{fd}-opened file descriptors are marked FDT_EXTERNAL.  We could default
to leaving those open on fork and document this.  This would then
apply to file descriptors created with zsocket, which I presume you
could think of as being in the same category.

sysopen file descriptors are marked FDT_INTERNAL, which we'd certainly
expect to close.  It looks like we make an exception if you use an
explicit file descriptor number rather than ask for one to be assigned
to a variable, I think because that's constrained to be 0 to 9.  So these
could be changed to FDT_EXTERNAL, too, which would probably be more
consistent.

As I said, this is just based on needs and documentation rather than any
definite logic.

Probably =(...) should use closem() consisent with <(...), too.

pws