nobody at nowhere.invalid
Wed Oct 22 04:49:43 CEST 2014
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.
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.
More information about the Python-list