Flush stdin

[Dan Stromberg]

On Sat, Oct 18, 2014 at 6:11 PM, Nobody <nobody at nowhere.invalid> wrote:
> On Sat, 18 Oct 2014 12:32:07 -0500, Tim Chase wrote:
>
>> On 2014-10-18 17:55, Nobody wrote:
>>> On Fri, 17 Oct 2014 12:38:54 +0100, Empty Account wrote:
>>>
>>> > I am using netcat to listen to a port and python to read stdin and
>>> > print to the console.
>>> >
>>> > nc -l 2003 | python print_metrics.py
>>> >
>>> > sys.stdin.flush() doesn’t seem to flush stdin,
>>>
>>> You can't "flush" an input stream.
>>
>> You can't flush it, but you can make it unbuffered.  You can either force
>> python to use unbuffered stdio:
>
> [snipped]
>
> None of this helps in any way, as it's not the behaviour of the Python
> script which is causing the problem, but that "nc" is (probably) buffering
> its output, so the data isn't passed to the OS (let alone to the Python
> script) in a timely manner.

Agreed.

> 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?

> it will be available to
> the Python script immediately thereafter without requiring any low-level
> tweaks.
Which, on a pipe, generally means either the buffer filled and needed
to be passed along to make room, or the process exited.

I'd probably rewrite just enough nc in Python to make it so you don't
need to depend on a pipe (example:
http://stromberg.dnsalias.org/~strombrg/pnetcat.html), but if you're
on *ix you could try
http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.unix/volume23/pty/
in an effort to persuade nc to think that it's on a tty and hence
should output line buffered data instead of block buffered - despite
being on a pipe in reality.

HTH.