From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id c73847be for ; Mon, 1 Jul 2019 20:01:12 +0000 (UTC) Received: (qmail 24215 invoked by alias); 1 Jul 2019 20:01:07 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44478 Received: (qmail 21374 invoked by uid 1010); 1 Jul 2019 20:01:07 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr1-f54.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25496. spamassassin: 3.4.2. Clear:RC:0(209.85.221.54):SA:0(-2.0/5.0):. Processed in 2.873699 secs); 01 Jul 2019 20:01:07 -0000 X-Envelope-From: stephane.chazelas@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.221.54 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=qNBPOtOJKhG2JI9pLoxG9b63AMn1RB5KCJMav/WQ/7k=; b=rbPQbH56Pp+M3tE0oKO/c4l7pRSprHcBvfKHpq//6uR2BCK1Ei0adyz18vKqs7ZaOV 3Q3c2TjmZ+G2LVkeIygzEuPpWj2Fv1PBZ+GX58MBypptb7E0nJm+KHbt/Ptfhl/RH09J EwiJ+frDEdKd7SYu8m/aQM/zUDW3AfYQUbgaOU3Ed8jeQmear8hqh3D2H+NRWeEkFE7t rWbMEnn0k3tJUEvSeRUI8OrN5z05y95s092A6uI+nITxQfKnyy8r/EQCsyZjDXpaMxZm sHxlzbpJibkbhLOs2rVOP/FQCGI1aNeHnXHT9jIPZCcvD2aFQgLiwDA6p679WiQqyo8w G42g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=qNBPOtOJKhG2JI9pLoxG9b63AMn1RB5KCJMav/WQ/7k=; b=QqJPZdggkwkCUjwbuuUpEfjxbxi82mwXkvuiV/VXou1V7kvZHFRke80duMzJgz7bOD U/IbEJnTNfeR6BZoKT9BYI3fR4S3VmCP8Ri09JXeFUjFnTZS2YVriEcosBfHFT5xIRml LKJqqXkwXeGI1Q2MGjEjzfMqOX+zAWUEFCZRaWiu4RgcMgfiIcIx/N064tN1aNt3igdc HZyjsq2dRE4vMJ6/x0GOiF9NAQxKkbrjn2FCMiYDGlbdqzN5bDFhXA3vDkS99v9tPDUw TA6uqEaTRk4Zh4h27MAdKo1BumrI/2sLP/eu6NzI4szUWb14trkTtLv7GFCfBm5yxKYd 0Gaw== X-Gm-Message-State: APjAAAUXtzezLvBp0xzEJ5I9a62MmVyfMfOOFyt2fm0XgAcRcc26QX1i 0Jj4FgKwPqXZAkMM243KQ0vv/Zde X-Google-Smtp-Source: APXvYqwqyzvYe1zcLiifkBAXm5Zbw13F7uCHGzRJdALkAZpBKOL2BOpUOmgNtmZ4G5WkYCMT2UqcaQ== X-Received: by 2002:adf:fb0b:: with SMTP id c11mr3885027wrr.51.1562011230369; Mon, 01 Jul 2019 13:00:30 -0700 (PDT) Date: Mon, 1 Jul 2019 21:00:28 +0100 From: Stephane Chazelas To: Peter Stephenson Cc: Zsh Hackers' List Subject: Re: <(...), >(...) and fds above 9 Message-ID: <20190701200028.5ehhz6nsitc3bzfn@chaz.gmail.com> Mail-Followup-To: Peter Stephenson , Zsh Hackers' List References: <20190701100001.hbegs7zyu2auckhf@chaz.gmail.com> <1561975733.6006.2.camel@samsung.com> <1561994908.6006.19.camel@samsung.com> <20190701162202.5o3cxahc75e2hucz@chaz.gmail.com> <1561999973.6006.21.camel@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1561999973.6006.21.camel@samsung.com> User-Agent: NeoMutt/20171215 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