Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The answer lies not in any magic related to the subprocess module, but in the typical behaviour of the <code>read()</code> method on Python objects.</p> <p>If you run this:</p> <pre><code>import subprocess p = subprocess.Popen(['ls'], stdout=subprocess.PIPE) help(p.stdout.read) </code></pre> <p>You'll see this:</p> <blockquote> <p>read(...)</p> <pre><code>read([size]) -&gt; read at most size bytes, returned as a string. If the size argument is negative or omitted, read until EOF is reached. Notice that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given. </code></pre> <p>(END)</p> </blockquote> <p>The same thing applies to all file-like objects. It's very simple: calling <code>read()</code> with no argument consumes the buffer until it encounters an error (usually EOF).</p> <p><code>EOF</code> is not sent until either:</p> <ul> <li>the subprocess calls sys.stdout.close(), or</li> <li>the subprocess exits and the Python runtime and/or OS kernel clean up its file descriptors</li> </ul> <p>Beware that <code>os.read</code> has different behaviour - much more like typical buffered I/O in C. The built-in Python help function is useless, but if you're on any UNIXy system you should be able to run <code>man 3 read</code>; the Python behaviour more or less matches what's there.</p> <h2>A word of warning</h2> <p>The program above is fine, but patterns like that sometimes lead to a deadlock. The docs for the subprocess module warns about this where Popen.wait() is documented:</p> <blockquote> <p>Warning</p> <p>This will deadlock when using stdout=PIPE and/or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that.</p> </blockquote> <p>It's possible to get in a similar situation if you're not careful during two-way communication with a subprocess, depending on what the subprocess is doing.</p> <p><strong>edit</strong>:</p> <p>By the way, <a href="http://man7.org/linux/man-pages/man7/pipe.7.html" rel="nofollow">this page</a> covers the behaviour of pipes with EOF:</p> <blockquote> <p>If all file descriptors referring to the write end of a pipe have been closed, then an attempt to read(2) from the pipe will see end-of-file (read(2) will return 0).</p> </blockquote> <p><strong>edit 2</strong>:</p> <p>As Lennart mentined above, if you want truly two-way communication that goes beyond write-once read-once, you'll also need to beware of buffering. If you read <a href="http://docs.python.org/2/library/stdtypes.html#bltin-file-objects" rel="nofollow">this</a> you'll get some idea of it, but you should be aware that this is how buffered IO almost always works in UNIX-based systems - it's not a Python quirk. Run <code>man stdio.h</code> for more information.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload