On Sat, 18 Oct 2014 18:42:00 -0700, Dan Stromberg wrote:
> On Sat, Oct 18, 2014 at 6:34 PM, Dan Stromberg <drsali...@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.
If it is, using a pseudo-tty would probably fix it. At startup,
stdin and stdout are line-buffered if they are associated with a tty and
fully-buffered otherwise (file, pipe, ...); stderr is unbuffered.
At least, this is the case on Unix and Windows. The exact requirements of
the C standard are:
As initially opened, the standard error stream is not fully
buffered; the standard input and standard output streams are
fully buffered if and only if the stream can be determined not
to refer to an interactive device.
--
https://mail.python.org/mailman/listinfo/python-list
