On Tue, Oct 21, 2014 at 7:49 PM, Nobody <[email protected]> wrote:
> On Sat, 18 Oct 2014 18:42:00 -0700, Dan Stromberg wrote:
>
>> On Sat, Oct 18, 2014 at 6:34 PM, Dan Stromberg <[email protected]> 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).
--
https://mail.python.org/mailman/listinfo/python-list
