Message7992

I see what is happening, running interactively under the debugger, but I'm not sure what to do about it. Two things are playing badly together: our expectations of jline and the design of (mainly) TextIOWrapper.

jline.WindowsTerminal.initializeTerminal() calls the low-level C-API setconsolemode (http://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).aspx) to:
1. Suppress echo
2. Suppress system trapping of the ctrl-C key (Issue #1313 ?)
3. Put the input into single character mode
These changes affect all input, whether read explicitly through jline or directly through System.in.

It's the last of these which is giving us the difference from InteractiveConsole. When sys.stdin.readline calls System.in.read(), it receives just one byte. That's ok, because this is happening within TextIOWrapper.readline(), which simply accumulates characters one at a time, looking for a line ending. When the user hits return, the character received is '\r', and TextIOWrapper goes back expecting a '\n'. If you sneak in a real line feed (Alt+0010) at this point, readline() returns, but who's going to think of that?

dev>jython -J-agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=y
Listening for transport dt_socket at address: 8000
Jython 2.7b1+ (default:96e2e620b894+, Mar 29 2013, 00:21:14)
[Java HotSpot(TM) 64-Bit Server VM (Sun Microsystems Inc.)] on java1.6.0_35
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> repr(sys.stdin.readline())
"'a\\n'"
>>>
Opening stdin in universal mode does not fix it because the check for the '\n' causes an extra byte to be read: readline returns, when you type an extra key after '\r', but it is then waiting in the input.

I should also investigate how this behaves when jython is a subprocess, in case it is differently broken.

Solution possibilities in my mind (assuming we want to keep jline):
1. Configuration of jline (but does that affect System.in).
2. Open sys.stdin so it treats just '\r' as the newline (when using jline).
3. sys.stdin needs to wrap calls to jline instead of calls to System.in.read().
4. Turn jline on and off (if possible) when reading the console, so other use of System.in is well-behaved.

I don't presently know how to do any of these, but could probably work it out, if it can be done.