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
a-time I/O in the tty driver via a variety of methods for
> portability. I wrote it in C before I took an interest in Python.
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 p
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
nd 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.
&g
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
e.
>> >
>> > 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
> pyth
seem to flush stdin,
You can't "flush" an input stream.
Sure you can.
You are collectively confusing three different meaning of 'flush'.
Python and its docs are the best authority on what python can and cannot
do. One can "call .flush() on an imput stream&
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
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 "
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
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"
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
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 stdo
Hi,
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.
while True:
input = sys.stdin.readline()
# do some parsing
29 matches
Mail list logo
