subprocess -- broken pipe error

Discussion in 'Python' started by 7stud, Jul 2, 2007.

  1. 7stud

    7stud Guest

    Hi,

    Can someone explain what a broken pipe is? The following produces a
    broken pipe error:

    ----------
    import subprocess as sub

    p = sub.Popen(["ls", "-al", "../"], stdin=sub.PIPE, stdout=sub.PIPE)

    print p.stdout.read()
    #outputs the files correctly

    p.stdin.write("ls\n")
    #IOError: [Errno 32] Broken pipe
    -----------
     
    7stud, Jul 2, 2007
    #1
    1. Advertising

  2. 7stud

    Guest

    On Jul 2, 1:12 pm, 7stud <> wrote:
    > Hi,
    >
    > Can someone explain what a broken pipe is? The following produces a
    > broken pipe error:
    >
    > ----------
    > import subprocess as sub
    >
    > p = sub.Popen(["ls", "-al", "../"], stdin=sub.PIPE, stdout=sub.PIPE)
    >
    > print p.stdout.read()
    > #outputs the files correctly
    >
    > p.stdin.write("ls\n")
    > #IOError: [Errno 32] Broken pipe
    > -----------


    You are seeing this error because sub.Popen closes both stdin and
    stdout once the subprocess terminates (which it must have done for
    p.stdout.read() to return a result).

    Consequently you are trying to write to a pipeline whose reader has
    already closed it, hence the error message.

    regards
    Steve
     
    , Jul 2, 2007
    #2
    1. Advertising

  3. 7stud

    7stud Guest

    On Jul 2, 11:32 am, "" <> wrote:
    > On Jul 2, 1:12 pm, 7stud <> wrote:
    >
    >
    >
    > > Hi,

    >
    > > Can someone explain what a broken pipe is? The following produces a
    > > broken pipe error:

    >
    > > ----------
    > > import subprocess as sub

    >
    > > p = sub.Popen(["ls", "-al", "../"], stdin=sub.PIPE, stdout=sub.PIPE)

    >
    > > print p.stdout.read()
    > > #outputs the files correctly

    >
    > > p.stdin.write("ls\n")
    > > #IOError: [Errno 32] Broken pipe
    > > -----------

    >
    > You are seeing this error because sub.Popen closes both stdin and
    > stdout once the subprocess terminates (which it must have done for
    > p.stdout.read() to return a result).
    >
    > Consequently you are trying to write to a pipeline whose reader has
    > already closed it, hence the error message.
    >
    > regards
    > Steve


    Hi,

    Thanks for the response. So are you saying that the only way you can
    get data out of a pipe is when the subprocess has terminated?
     
    7stud, Jul 2, 2007
    #3
  4. 7stud

    7stud Guest

    Why doesn't the following program write to the file?

    driver.py
    -------
    import subprocess as sub

    p = sub.Popen(["python", "-u", "test1.py"], stdin=sub.PIPE,
    stdout=sub.PIPE)


    p.stdin.write("text3")

    while True:
    pass
    -------

    test1.py:
    ---------
    import sys

    data = sys.stdin.read()

    f = open("aaa.txt", "w")
    f.write(data + "\n")
    f.close()
    -----------


    After I hit Ctrl+C to end the program and look in the file, the text
    wasn't written to the file. But, if I change driver.py to the
    following it works:

    driver.py:
    ----------
    import subprocess as sub

    p = sub.Popen(["python", "-u", "test1.py"], stdin=sub.PIPE,
    stdout=sub.PIPE)


    p.stdin.write("text3")
    -------

    Ok. So that looks like the data is caught in a buffer--even though the
    pipes should be unbuffered by default. But this doesn't work:

    driver.py
    ----------
    import subprocess as sub

    p = sub.Popen(["python", "-u", "test1.py"], stdin=sub.PIPE,
    stdout=sub.PIPE)

    p.stdin.write("text4")
    p.stdin.flush()

    while True:
    pass
    -------

    It just hangs, and then when I hit Ctrl+C and look in the file, the
    data isn't in there.
     
    7stud, Jul 2, 2007
    #4
  5. 7stud wrote:

    > Thanks for the response. So are you saying that the only way you
    > can get data out of a pipe is when the subprocess has terminated?


    No, not only because Pipes aren't related to processes in any
    special way.

    He said that you can't write to a pipe whose reader has already
    terminated.

    Regards,


    Björn

    --
    BOFH excuse #36:

    dynamic software linking table corrupted
     
    Bjoern Schliessmann, Jul 2, 2007
    #5
  6. 7stud wrote:

    > Why doesn't the following program write to the file?
    > [...]
    > It just hangs, and then when I hit Ctrl+C and look in the file,
    > the data isn't in there.


    I suppose your running child process isn't closed cleanly if you
    terminate the parent process. Also, the pipe may be unbuffered by
    default; file access isn't.

    Regards,


    Björn

    --
    BOFH excuse #384:

    it's an ID-10-T error
     
    Bjoern Schliessmann, Jul 2, 2007
    #6
  7. 7stud

    7stud Guest

    On Jul 2, 1:58 pm, Bjoern Schliessmann <usenet-
    > wrote:
    > 7stud wrote:
    > > Thanks for the response. So are you saying that the only way you
    > > can get data out of a pipe is when the subprocess has terminated?

    >
    > No, not only because Pipes aren't related to processes in any
    > special way.
    >
    > He said that you can't write to a pipe whose reader has already
    > terminated.
    >


    What he said was:

    >...once the subprocess terminates (which it must have done for
    >p.stdout.read() to return a result)


    And based on the results of the examples I posted in my last post, it
    seems to confirm that no data travels through a pipe until a program
    on one side of the pipe has terminated.
     
    7stud, Jul 2, 2007
    #7
  8. 7stud

    7stud Guest

    On Jul 2, 2:03 pm, Bjoern Schliessmann <usenet-
    > wrote:
    > 7stud wrote:
    > > Why doesn't the following program write to the file?
    > > [...]
    > > It just hangs, and then when I hit Ctrl+C and look in the file,
    > > the data isn't in there.

    >
    > Also, the pipe may be unbuffered by
    > default; file access isn't.
    >


    f.close() flushes the buffer to a file.
     
    7stud, Jul 2, 2007
    #8
  9. 7stud

    Steve Holden Guest

    7stud wrote:
    > Why doesn't the following program write to the file?
    >
    > driver.py
    > -------
    > import subprocess as sub
    >
    > p = sub.Popen(["python", "-u", "test1.py"], stdin=sub.PIPE,
    > stdout=sub.PIPE)
    >
    >
    > p.stdin.write("text3")
    >
    > while True:
    > pass
    > -------
    >
    > test1.py:
    > ---------
    > import sys
    >
    > data = sys.stdin.read()
    >

    Let me ask you a question: what conditions have to be true to this
    statement to terminate?

    A: the Python driver.py process has to close its output file. Since it
    doesn't do this (instead writing a little bit of output then going into
    an infinite loop) the whole thing just sits there consuming CPU time.


    > f = open("aaa.txt", "w")
    > f.write(data + "\n")
    > f.close()
    > -----------
    >
    >
    > After I hit Ctrl+C to end the program and look in the file, the text
    > wasn't written to the file. But, if I change driver.py to the
    > following it works:
    >
    > driver.py:
    > ----------
    > import subprocess as sub
    >
    > p = sub.Popen(["python", "-u", "test1.py"], stdin=sub.PIPE,
    > stdout=sub.PIPE)
    >
    >
    > p.stdin.write("text3")
    > -------
    >
    > Ok. So that looks like the data is caught in a buffer--even though the
    > pipes should be unbuffered by default. But this doesn't work:
    >

    Who told you pipes should be unbuffered by default, and what difference
    does that make anyway?

    The reason it works now is that your program closes its standard output
    by default when it terminates.

    > driver.py
    > ----------
    > import subprocess as sub
    >
    > p = sub.Popen(["python", "-u", "test1.py"], stdin=sub.PIPE,
    > stdout=sub.PIPE)
    >
    > p.stdin.write("text4")
    > p.stdin.flush()
    >
    > while True:
    > pass
    > -------
    >
    > It just hangs, and then when I hit Ctrl+C and look in the file, the
    > data isn't in there.
    >

    Of course it does, for the reasons mentioned above. file.read() only
    returns when it has consumed *all* the data from the file (which means
    the write must close the file for the reader to be able to return).

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://del.icio.us/steve.holden
    --------------- Asciimercial ------------------
    Get on the web: Blog, lens and tag the Internet
    Many services currently offer free registration
    ----------- Thank You for Reading -------------
     
    Steve Holden, Jul 2, 2007
    #9
  10. 7stud

    7stud Guest

    On Jul 2, 2:12 pm, Steve Holden <> wrote:
    > a) Who told you pipes should be unbuffered by default, and b) what difference
    > does that make anyway?
    >


    a) The docs.

    b) If the pipes were buffered then writing a small amount of data like
    "text3" to the pipe would cause the other side to hang forever thereby
    providing a possible explanation for the results.

    >
    > > It just hangs, and then when I hit Ctrl+C and look in the file, the
    > > data isn't in there.

    >
    > Of course it does, for the reasons mentioned above. file.read() only
    > returns when it has consumed *all* the data from the file (which means
    > the write must close the file for the reader to be able to return).
    >


    That doesn't seem like a very good explanation, since the only thing
    written to the file(i.e. stdin) was "text3", and the write() was
    unbuffered, so the read() could consume all the data without the
    write() closing the file--there was no more data.
     
    7stud, Jul 2, 2007
    #10
  11. 7stud

    Steve Holden Guest

    7stud wrote:
    > On Jul 2, 1:58 pm, Bjoern Schliessmann <usenet-
    > > wrote:
    >> 7stud wrote:
    >>> Thanks for the response. So are you saying that the only way you
    >>> can get data out of a pipe is when the subprocess has terminated?

    >> No, not only because Pipes aren't related to processes in any
    >> special way.
    >>
    >> He said that you can't write to a pipe whose reader has already
    >> terminated.
    >>

    >
    > What he said was:
    >
    >> ...once the subprocess terminates (which it must have done for
    >> p.stdout.read() to return a result)

    >
    > And based on the results of the examples I posted in my last post, it
    > seems to confirm that no data travels through a pipe until a program
    > on one side of the pipe has terminated.
    >

    No, you plonker!

    No data is produced *by .read()* until the writer has closed it.

    I really don't remember anyone in recent history as eager to willfully
    misunderstand any attempted assistance. Please try to read what is
    written more carefully. It's most annoying when "the better the advice
    the worse it's wasted", as the Scots say.

    Please forgive my brusqueness.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://del.icio.us/steve.holden
    --------------- Asciimercial ------------------
    Get on the web: Blog, lens and tag the Internet
    Many services currently offer free registration
    ----------- Thank You for Reading -------------
     
    Steve Holden, Jul 2, 2007
    #11
  12. 7stud

    Steve Holden Guest

    7stud wrote:
    > On Jul 2, 2:12 pm, Steve Holden <> wrote:
    >> a) Who told you pipes should be unbuffered by default, and b) what difference
    >> does that make anyway?
    >>

    >
    > a) The docs.
    >
    > b) If the pipes were buffered then writing a small amount of data like
    > "text3" to the pipe would cause the other side to hang forever thereby
    > providing a possible explanation for the results.
    >
    >>> It just hangs, and then when I hit Ctrl+C and look in the file, the
    >>> data isn't in there.

    >> Of course it does, for the reasons mentioned above. file.read() only
    >> returns when it has consumed *all* the data from the file (which means
    >> the write must close the file for the reader to be able to return).
    >>

    >
    > That doesn't seem like a very good explanation, since the only thing
    > written to the file(i.e. stdin) was "text3", and the write() was
    > unbuffered, so the read() could consume all the data without the
    > write() closing the file--there was no more data.
    >

    [sigh].

    So please explain how the receiving process mysteriously manages to look
    inside your producer process to know that it is never going to produce
    any more data. Let's (briefly) look at the docs for read():

    """
    read( [size])

    Read at most size bytes from the file (less if the read hits EOF before
    obtaining size bytes). If the size argument is negative or omitted, read
    all data until EOF is reached. ...
    """

    I believe you omitted the argument. As I have explained, the read() call
    therefore waits until the writer has closed the file. Which is what
    makes the EOF indication appear.

    And please stop dragging buffering into this as a red herring. You do
    know what buffering *is*, I take it? The read() call buffers even an
    unbuffered source, by definition.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://del.icio.us/steve.holden
    --------------- Asciimercial ------------------
    Get on the web: Blog, lens and tag the Internet
    Many services currently offer free registration
    ----------- Thank You for Reading -------------
     
    Steve Holden, Jul 2, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Clive
    Replies:
    0
    Views:
    3,009
    Clive
    Aug 12, 2003
  2. Junhua Deng (AL/EAB)

    socket.error: (32, 'Broken pipe'): need help

    Junhua Deng (AL/EAB), Oct 27, 2005, in forum: Python
    Replies:
    1
    Views:
    1,170
    dcrespo
    Oct 27, 2005
  3. Jeremy Jones
    Replies:
    0
    Views:
    5,733
    Jeremy Jones
    Oct 27, 2005
  4. Steven K. Wong
    Replies:
    6
    Views:
    1,036
    Nobody
    Jan 10, 2010
  5. nicholas.henry
    Replies:
    0
    Views:
    225
    nicholas.henry
    May 21, 2006
Loading...

Share This Page