subprocess -- broken pipe error

[7stud]

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
-----------

[holdenweb]

On Jul 2, 1:12 pm, 7stud <[e-mail]:

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

[7stud]

On Jul 2, 11:32 am, "[e-mail]" <[e-mail]:

On Jul 2, 1:12 pm, 7stud <[e-mail]:

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]

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.

[Bjoern Schliessmann]

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]

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

[7stud]

On Jul 2, 1:58 pm, Bjoern Schliessmann <usenet-
[e-mail]:

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]

On Jul 2, 2:03 pm, Bjoern Schliessmann <usenet-
[e-mail]:

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.

[Steve Holden]

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 [phone] [phone]
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 -------------

[7stud]

On Jul 2, 2:12 pm, Steve Holden <[e-mail]:

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.

[Steve Holden]

7stud wrote:

On Jul 2, 1:58 pm, Bjoern Schliessmann <usenet-
[e-mail]:

>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 [phone] [phone]
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]

7stud wrote:

On Jul 2, 2:12 pm, Steve Holden <[e-mail]:

>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 [phone] [phone]
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 -------------