Flush stdin

Dan Stromberg drsalists at gmail.com
Wed Oct 22 05:11:34 CEST 2014

On Tue, Oct 21, 2014 at 7:49 PM, Nobody <nobody at nowhere.invalid> wrote:
> On Sat, 18 Oct 2014 18:42:00 -0700, Dan Stromberg wrote:
>> On Sat, Oct 18, 2014 at 6:34 PM, Dan Stromberg <drsalists at gmail.com> wrote:
>>>> Once the "nc" process actually write()s the data to its standard
>>>> output (i.e. desriptor 1, not the "stdout" FILE*)
>>> I'm not sure why you're excluding stdout, but even if nc is using
>>> filedes 1 instead of FILE * stdout, isn't it kind of irrelevant?
>> On further reflection, isn't it stdio that does the varied buffering,
>> and filedes 1 that's always unbuffered?  IOW, the OP might wish nc was
>> using 1, but it probably can't be given what they're seeing.
> Yes. stdio does buffering. Writing to stdout stores data in a buffer; that
> data should eventually be written to descriptor 1, although perhaps not
> until immediately prior to termination.
> Which is probably the cause of the OP's problem.

Huh.  And here I thought I demonstrated elsewhere in this thread, that
the buffering between nc and python didn't appear to be the problem.

'found it, here it is again:

If I run the following in one tty:
    nc -l localhost 9000 | /tmp/z

...where /tmp/z has just:

    import sys

    for line in sys.stdin.buffer:

And then run the following in another tty on the same computer:
    while read line; do echo $line; sleep 1; done < /etc/passwd | nc
localhost 9000

...then everything acts line buffered, or perhaps even character
buffered (the two are pretty indistinguishable in this test).  What I
see is my /etc/passwd file popping out of the nc -l side, one line at
a time, each line one second apart.

I suppose this suggests that it's the client that's sending TCP data
that is buffering.

That, or we're using two different versions of netcat (there are at
least two available).

More information about the Python-list mailing list