On Thu, Sep 22, 2016, at 09:45, eryk sun wrote:
> On Thu, Sep 22, 2016 at 12:40 PM, Gregory Ewing
> <greg.ew...@canterbury.ac.nz> wrote:
> > eryk sun wrote:
> >> Actually in a Unix terminal the cursor can also be at
> >> the end of a line, but a bug in Python requires pressing Ctrl+D twice
> >> in that case.
> > I wouldn't call that a bug, rather it's a consequence of
> > what Ctrl-D does. It doesn't really mean EOF, it means to
> > send whatever the terminal driver has in its input buffer.
> > If the buffer is empty at the time, the process gets a
> > zero-length read which is taken as EOF. But if the buffer
> > is not empty, it just gets whatever is in the buffer.
> > There's nothing Python can do about that, because it
> > never sees the Ctrl-D -- that's handled entirely by the
> > terminal driver.
> Yes, FileIO.readall continues making read() system calls until it sees
> an empty read. But if we know we're reading from a terminal, we should
> be able to assume that a read either consumes an entire line up to a
> newline character or the entire buffer, no? In other words, if we see
> a read that returns less than the buffer size but doesn't end on a
> newline, then for a terminal, and only a terminal, I think we can
> infer Ctrl+D was typed and handle it as EOF.
I don't see where you're getting that users should even expect ctrl-d at
the end of a line to be treated as EOF. It doesn't behave that way in
any other program - try it in cat, dash, etc. There are also other
circumstances that can cause a partial read. For example, if the user
types the dsusp character (^Y by default) on systems that support it,
the program will be suspended and will receive a partial read when
resumed. I wouldn't bet on a guarantee that you can't get a partial read
if input is too long to fit in the driver's edit buffer (which may be
smaller than the program's read buffer) on some platforms (though when
I've tried it it simply stops accepting input until I hit ctrl-D or
enter)... and savvy users may deliberately type ctrl-D for this purpose.
And, of course, in readline, the terminal is really in cbreak mode and
Python receives an actual Ctrl+D rather than having to infer anything.
But here, too, other programs ignore it just like Python: try it in
bash, zsh, etc.
The only "bug" is in some users' simplistic understanding that "ctrl-D