Pasting code into the cmdline interpreter

[eryk sun]

On Thu, Sep 22, 2016 at 3:21 PM, Random832 <random832 at fastmail.com> wrote:
> On Thu, Sep 22, 2016, at 09:45, eryk sun wrote:
>
>> 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.

I thought it could be avoided as a convenience by inferring EOF when
reading from a terminal, but clearly that's not the case.

> 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 didn't consider this, which means I'm stuck with double tapping
Ctrl+D to get exactly the pasted input without adding an extra
newline.

This is on my mind because I want to add Ctrl+D support for console
I/O in Windows, for consistency with Unix terminals and IDLE. With how
this works on Windows, the read returns with the control character
still in the buffer (e.g. '\x04'), so you know exactly what the user
typed. But I see now that it should retain the default readall()
behavior to only count an empty read (from the function that wraps
ReadConsoleW) as EOF.