popen2.Popen3 and slightly large output

[mike wakerly]

Hi Donn,

"Donn Cave" <donn at drizzle.com> wrote in message:
> Quoth Mike Wakerly <mikew at wakerly.com>:
> ...
> | However, I have encountered a behaviour in
> | popen2.Popen3 that I cannot fully explain; rather I
> | can only gruffly mumble things about 'buffers getting
> | filled' and such...
> 
> No doubt that's it.

I can't see how. I've tried the obvious route -- setting the
popen2.Popen3 bufsize to zero showed no difference. (The default of -1
looks to be the same). I should say that of course the behaviour still
suggests to me that _some_ buffer for _something_ is not being
flushed, but I think it is buried much lower in the implemntation --
where I lack the expertise.

Studying the implementation (see below) has not helped much; I wonder
if by running the sample script I attached, anything jumps out at
someone who has used the module more? It certainly surprises me. I'm
not even bothering with sending the process input

> | What can cause this? My suspicion is that somehow, the
> | output is buffered, and somehow, inspecting fromchild
> | flushes said buffer, and the process completes. I have
> | yet to inspect the actual Popen3 implementation
> 
> Tsk.  It's in popen2.py in your library directory.  Take a
> look.  There really isn't much to it, and you are almost
> guaranteed to learn something useful.

I should have rephrased that to read that no inspection was
clue-yielding <wink>. I did indeed look at popen2 and friends a few
times. I got so far as recognizing the input and output as file
descriptors of pipes, but what part of this sort of connection would
cause this? If anything, I would expect _smaller_ amounts of output to
cause this non-flushing behaviour. I'd gathered that the underlying os
pipe is block-buffered on my os (Linux). What I do not know is how to
flush this, if this is indeed the buffer in question (and why my
combination of more lines causes this, while a single character output
will not..)

As always, I appreciate the insight. 

Cheers,
Mike