Flush stdin

[Dan Stromberg]

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:
    #!/usr/bin/python3

    import sys

    for line in sys.stdin.buffer:
        print(line)

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