Weird behaviour?

[Steven D'Aprano]

On Mon, 22 Apr 2013 10:56:11 +1000, Chris Angelico wrote:

> You're running this under Windows. The convention on Windows is for
> end-of-line to be signalled with \r\n, but the convention inside Python
> is to use just \n. With the normal use of buffered and parsed input,
> this is all handled for you; with unbuffered input, that translation
> also seems to be disabled, so your string actually contains '120\r', as
> will be revealed by its repr().


If that's actually the case, then I would call that a bug in raw_input.

Actually, raw_input doesn't seem to cope well with embedded newlines even 
without the -u option. On Linux, I can embed a control character by 
typing Ctrl-V followed by Ctrl-<char>. E.g. Ctrl-V Ctrl-M to embed a 
carriage return, Ctrl-V Ctrl-J to embed a newline. So watch:


[steve at ando ~]$ python2.7 -c "x = raw_input('Hello? '); print repr(x)"
Hello? 120^M^Jabc
'120\r'

Everything after the newline is lost.


-- 
Steven