zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh Hackers' List <zsh-workers@zsh.org>
Subject: Re: <(...), >(...) and fds above 9
Date: Mon, 1 Jul 2019 17:52:53 +0100	[thread overview]
Message-ID: <1561999973.6006.21.camel@samsung.com> (raw)
In-Reply-To: <20190701162202.5o3cxahc75e2hucz@chaz.gmail.com>

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


  reply	other threads:[~2019-07-01 16:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190701100058epcas2p25e5f8dbd14d048fe2be1d831f3cf60ab@epcas2p2.samsung.com>
2019-07-01 10:00 ` Stephane Chazelas
2019-07-01 10:08   ` Peter Stephenson
2019-07-01 14:39     ` Bart Schaefer
2019-07-01 15:28       ` Peter Stephenson
2019-07-01 16:22         ` Stephane Chazelas
2019-07-01 16:52           ` Peter Stephenson [this message]
2019-07-01 17:00             ` Peter Stephenson
2019-07-01 20:00             ` Stephane Chazelas
2019-07-01 20:06               ` Bart Schaefer
2019-07-02  8:59             ` Peter Stephenson
2019-07-02 12:20               ` Stephane Chazelas
2019-07-02 13:12                 ` Peter Stephenson
2019-07-02 15:19                   ` Stephane Chazelas
2019-07-02 15:21                     ` Peter Stephenson
2019-07-02 16:43                 ` Sebastian Gniazdowski
2019-07-02 18:08                   ` Stephane Chazelas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1561999973.6006.21.camel@samsung.com \
    --to=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).