From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16188 invoked by alias); 13 Aug 2017 18:49:42 -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: X-Seq: 41537 Received: (qmail 26046 invoked by uid 1010); 13 Aug 2017 18:49:42 -0000 X-Qmail-Scanner-Diagnostics: from mail-qk0-f177.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.220.177):SA:0(-0.0/5.0):. Processed in 1.968061 secs); 13 Aug 2017 18:49:42 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/zyLrJKcvxPioXme2VOj8Jaz74mfsl7stmSIhD1i5+E=; b=Ulsr2Xse24uCLdkoE+renuZa/T0RS3JIpeWkVI3ht3VKer1tokWwKDkXwQf30CiRvA pfE+48CLLEdqjA6ysohsaYS6/8zbwj+sns5B1wez8nBQP9OLP4PzQ1xin5Mrld1dEHp8 mhuyNK2P2qFpRGqaQTZ9MPty2SrkGbo161rFOYzi/1buOJnbHkX9AAG/61ta7yc0OMjW aEarWc0KNZ8aCazrM0bL/jgNgluo2do98ew6bazxh9UvFl+fh5Mj78UOZvlqGwEKWv3b CB5Cpsd9107E4sc4OfkzhHi6LLL+lh/UGIBe98XATFgkN9d3Nf+reomM5h+Kcbmw0IDC wtRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/zyLrJKcvxPioXme2VOj8Jaz74mfsl7stmSIhD1i5+E=; b=TLbtG/K6wjpBiPFmMpRL24nn0OIy+uHr/hW5t3Go8f0Fe/W8BCSx2ExWWtjuJQ1r7C f5kI+9t0Wentaqb4RoHjNZlUrJH/PqxyzSc5akGuohyfBQCrRoIFu5mHuVMOtLzxvVyg qw4sW/uf93KwgsUWMglvlXPO1YPYliDelUO8MnX4/Ok8Wi67BTygAcOiC+0mBXyxHOEO 1K2j2skVKPCEbRD+uPa0hZbFiHuzkCW/oHewjWHqkiKTCl85PoFmeQNwsyksiaHlgpDK 2erkK+vil1p34pYlN1I3o5xCLSV5t4zuTw/rrI9/QLGAwutC87BcAjc6ScuPa2+Zm0uC 24aA== X-Gm-Message-State: AHYfb5hbwNLJg7LALly0iqBnNVCwsuWSX7XX+NJlxqVvaoLiBQUT2fkH 84X7/IXyHpD8CLZC43C1o30YvUxKvcCw X-Received: by 10.55.23.5 with SMTP id i5mr3745859qkh.116.1502650175099; Sun, 13 Aug 2017 11:49:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170813161207.GA6530@chaz.gmail.com> References: <20170813161207.GA6530@chaz.gmail.com> From: Bart Schaefer Date: Sun, 13 Aug 2017 11:49:34 -0700 Message-ID: Subject: Re: fd used for saving redirected fds leaked to child processes To: Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Sun, Aug 13, 2017 at 9:12 AM, Stephane Chazelas wrote: > In: > > mkfifo fifo > zsh -c '{ echo GO > fifo & echo $!; } > pid; echo done' | cat > > "cat" hangs until some process open the fifo in read mode, even > though that "echo GO > fifo" command was run in background and > "done" is output straight away. Hmm. Here in a bit more detail is what I believe is going on: There is a parent shell (probably also zsh in this example) managing the two processes "zsh -c ..." and "cat". Following zsh's usual practice, the "zsh -c" process has been forked (in case "cat" is a builtin) and then "cat" has also been forked (because it's not a builtin). Thus the stdin of "cat" is connected to the stdout of "zsh -c" as you would expect. Looking inside that "zsh -c", the "{ ... }" construct is supposed to be executed in the current shell. So *that* zsh saves its stdout as fd 12, redirects the "{ ... }" output to the "pid" file, and begins handling what's inside the braces. At this point fd 12 cannot be closed, because the current shell still needs it in order to restore stdout. Now zsh does "echo GO > file &". It is after zsh forks to background this process that fd 12 might become irrelevant. However, (the subtle bit), zsh attempts to process all the redirections first, before doing the cleanup of the file descriptors that the child process doesn't need. So it blocks on opening the fifo with fd 12 still open, even though it would eventually close fd 12 before "echo" is executed. You can demonstrate this because even using /bin/echo in the example above, which would invoke the close-on-exec flag, still blocks in exactly the same way. The question is how it's possible to address this without "accidentally" closing descriptors that might legitimately be managed with further redirections e.g. X>&Y.