Flush stdin

[Cameron Simpson]

On 18Oct2014 18:42, Dan Stromberg <drsalists at gmail.com> 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.

Traditionally, fd 1 (standard output, _generally_ associated with FILE 
*stdout), gets stdio buffering; line buffered for a terminal, block buffered 
otherwise. fd 2 (standard error, _generally_ associated with FILE *stderr) gets 
an unbuffered stdio stream by default.

However, nc may well be behaving like "tail -f": always unbuffered.

However, as I recall the OP seemed to want to "flush" the stream from nc to 
python. Even if nc itself does no buffering (handing data to the OS as soon as 
received, highly desirable for a tool like nc), the OS keeps a buffer for the 
pipeline between nc and python, and python itself keeps a buffer for sys.stdin.

Both of those are candidates for some kind of flush/discard. IF (a big IF) that 
is what the OP really needs.

Have we heard anything from the OP since this discussion took off?

I think we need to better understand his/her use case.

Cheers,
Cameron Simpson <cs at zip.com.au>

Do you even know anything about perl? - AC replying to Tom Christiansen post