RE:#210676
System: Python 2.0 on solaris 8

The above bug is reported closed but I cannot see why.

>>> sub = popen2.Popen3(cmd,1)
>>> sub.fromchild.readlines()  # blocked on stderr


As reported in the above sited bug report, we too are
suffering from this behaviour on file objects returned
by popen3.  It does appear that the stderr buffer is
filling (the app writes a lot of stuff to stderr) and
blocking stdout, but i cannot seem to flush the
buffer.  I need to acquire both stderr and stdout
data.  I have tried setting the bufsize to 0
(unbuffered) but that doesn't work.  I have made the
buffer big, but nothing there.  Might there be
some magic bufsize?

popen4 (which stuffs both stderr and stdout into one
file object) works perfectly as there is no blocking.  

Reading through the bugs about popen3, the bug report
above is exactly what we are experiencing.  The
"solution" offered is not a solution at all. We are
running 3rd party code, i.e. we can't close stderr
inside the application, nor would we want to. stderr
and stdout file descriptors must remain open for
the duration of the application.

Has there been some viable solution to this which has
not been documented?

Logged In: YES 
user_id=7887

You can workaround the problem in the following ways:  
  
1) as martin explained in the previous mentioned bug;  
  
2)  using non-blocking I/O:   
     
fd = pop.childerr.fileno()     
flags = fcntl.fcntl (fd, fcntl.F_GETFL, 0)     
flags = flags | os.O_NONBLOCK     
fcntl.fcntl (fd, fcntl.F_SETFL, flags)     
     
3) piping the child error into /dev/null, if you don't want it.     
  
Either way, IMO that's something which belongs to how the operating  
system deals with that, since there's no way for Python to guess what  
you'd expect it to do in all possible cases, and it probably shouldn't try to.     
  
I suggest closing that bug. 
  

Logged In: YES 
user_id=11375

Marking as closed.  (Unless someone can suggest text to be added to the documentation to clarify this?)