From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: fd used for saving redirected fds leaked to child processes
Date: Sun, 13 Aug 2017 11:49:34 -0700 [thread overview]
Message-ID: <CAH+w=7bd82GmiirJcfp0xVwqY711OLqdQ0v5p1+=QXjM3Z0zQg@mail.gmail.com> (raw)
In-Reply-To: <20170813161207.GA6530@chaz.gmail.com>
On Sun, Aug 13, 2017 at 9:12 AM, Stephane Chazelas
<stephane.chazelas@gmail.com> 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.
next prev parent reply other threads:[~2017-08-13 18:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-13 16:12 Stephane Chazelas
2017-08-13 18:49 ` Bart Schaefer [this message]
2017-08-13 18:49 ` Peter Stephenson
2017-08-13 21:45 ` Bart Schaefer
2017-08-14 9:09 ` Peter Stephenson
2017-08-14 14:49 ` Bart Schaefer
2017-08-14 15:24 ` Peter Stephenson
2017-08-14 15:31 ` Bart Schaefer
2017-08-14 19:19 ` Peter Stephenson
2017-09-29 15:06 ` Daniel Shahaf
2017-09-29 15:18 ` Peter Stephenson
2017-08-15 18:42 ` Peter Stephenson
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='CAH+w=7bd82GmiirJcfp0xVwqY711OLqdQ0v5p1+=QXjM3Z0zQg@mail.gmail.com' \
--to=schaefer@brasslantern.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).