random...@fastmail.us:
> Yes, and 90% of the time, when someone says they want to "flush
> stdin", what they really want to do is go to the next line after
> they've sloppily read part of the line they're on (and the behavior
> they are seeing that they object to is that their next read function
>
On Tue, Oct 21, 2014, at 19:16, Dan Stromberg wrote:
> Actually, doesn't line buffering sometimes exist inside an OS kernel?
> stty/termios/termio/sgtty relate here, for *ix examples. Supporting
> code: http://stromberg.dnsalias.org/~strombrg/ttype/ It turns on
> character-at-a-time I/O in the tt
Dan Stromberg :
> On Mon, Oct 20, 2014 at 9:41 PM, Marko Rauhamaa wrote:
>> Terminal devices support line buffering on write.
> Yes, though that's not the only place it's useful.
>
>> Line buffering on read is an illusion created by higher-level libraries.
>> The low-level read function reads in
On Wed, Oct 22, 2014 at 4:38 PM, Marko Rauhamaa wrote:
> Dan Stromberg :
>
>> On Mon, Oct 20, 2014 at 9:41 PM, Marko Rauhamaa wrote:
>>> Nagle affects the communication between the peer OS kernels and isn't
>>> directly related to anything the application does.
>>
>> Actually, Nagle can cause two
Dan Stromberg :
> On Mon, Oct 20, 2014 at 9:41 PM, Marko Rauhamaa wrote:
>> Nagle affects the communication between the peer OS kernels and isn't
>> directly related to anything the application does.
>
> Actually, Nagle can cause two or more small packets to be merged,
> which is something an app
On Tue, Oct 21, 2014 at 7:49 PM, Nobody wrote:
> On Sat, 18 Oct 2014 18:42:00 -0700, Dan Stromberg wrote:
>
>> On Sat, Oct 18, 2014 at 6:34 PM, Dan Stromberg wrote:
Once the "nc" process actually write()s the data to its standard
output (i.e. desriptor 1, not the "stdout" FILE*)
>>> I'm
On Sat, 18 Oct 2014 18:42:00 -0700, Dan Stromberg wrote:
> On Sat, Oct 18, 2014 at 6:34 PM, Dan Stromberg 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 i
On 21Oct2014 16:16, Dan Stromberg wrote:
[...snip...]
This is tremendously inefficient. It demands a context switch for
every character.
Inefficiency isn't an issue when you generate one byte a second.
Of course, but who's doing one byte per second? You and I in our
tests, and perhaps some
On Mon, Oct 20, 2014 at 9:41 PM, Marko Rauhamaa wrote:
> Dan Stromberg :
>
>> Often with TCP protocols, line buffered is preferred to character
>> buffered,
>
> Terminal devices support line buffering on write.
Yes, though that's not the only place it's useful.
> Line buffering on read is an ill
Dan Stromberg :
> Often with TCP protocols, line buffered is preferred to character
> buffered,
Terminal devices support line buffering on write.
Line buffering on read is an illusion created by higher-level libraries.
The low-level read function reads in blocks of bytes.
> Also, it's a straigh
On Mon, Oct 20, 2014 at 4:18 PM, Marko Rauhamaa wrote:
> Dan Stromberg :
>> ...then everything acts line buffered, or perhaps even character
>> buffered [...]
>>
>> That, or we're using two different versions of netcat (there are at
>> least two available).
>
> Let's unconfuse the issue a bit. I'l
Dan Stromberg :
> ...then everything acts line buffered, or perhaps even character
> buffered [...]
>
> That, or we're using two different versions of netcat (there are at
> least two available).
Let's unconfuse the issue a bit. I'll take line buffering, netcat and
the OS out of the picture.
He
Dan Stromberg :
> On Sun, Oct 19, 2014 at 9:45 PM, Marko Rauhamaa wrote:
>> I found this comment in CPython's source code (pythonrun.c):
>>
>> /* stdin is always opened in buffered mode, first because it shouldn't
>>make a difference in common use cases, second because TextIOWrapper
>
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;
On Sun, Oct 19, 2014 at 9:45 PM, Marko Rauhamaa wrote:
> I found this comment in CPython's source code (pythonrun.c):
>
> /* stdin is always opened in buffered mode, first because it shouldn't
>make a difference in common use cases, second because TextIOWrapper
>depends on the
On 18Oct2014 18:42, Dan Stromberg wrote:
On Sat, Oct 18, 2014 at 6:34 PM, Dan Stromberg 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
Cameron Simpson :
> 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,
Yes, there is a buffer associated with the pipe, but linux/unix never
withholds any data fro
On Sat, Oct 18, 2014 at 6:34 PM, Dan Stromberg 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
On Sat, Oct 18, 2014 at 6:11 PM, Nobody 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
On Fri, Oct 17, 2014 at 10:38 PM, 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
After lengthy discussion about what it means to flush stdin, I think
it's high time someone asked the questi
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.
On 10/18/2014 5:01 PM, Cameron Simpson wrote:
On 18Oct2014 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 see
On 18Oct2014 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
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
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,
>
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.
> so I am using t
On 17Oct2014 12:38, 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, so I am using the termios
module.
You're aware that a stdio flush and a termi
On Fri, Oct 17, 2014 at 10:38 PM, Empty Account wrote:
> I will be using this script on Unix based systems and I wondered what
> approach I could use
> to flush stdin?
Why exactly do you need to flush stdin? If you've written a small
amount of data to the console, it's stdout that you need to flu
28 matches
Mail list logo
