On 08Jul2016 16:17, John Nagle <na...@animats.com> wrote:
If "readline" is imported, "input" gets "readline" capabilities.
It also loses the ability to import control characters. It doesn't
matter where "readline" is imported; an import in some library
module can trigger this. You can try this with a simple test
case:
print(repr(input()))
as a .py file, run in a console. Try typing "aaaESCbbb".
On Windows 7, output is "bbb". On Linux, it's "aaa\x1bbbb".
So it looks like "readline" is implicitly imported on Windows.
_Or_ that the Windows console app does its own input processing. I would be
_very_ surprised if Python were behaving differently on the two platforms in
this regard, though it is possible. (Disclaimer: I pretty much don't use
Windows).
Remember that any terminal program does some processing of keystrokes before
they reach your program, even if that is "no" processing. On a UNIX system this
is called the "line discipline", and doubtless Windows does something of that
nature.
On a UNIX system in normal circumstances your terminal's line discipline is in
"cooked" mode, where various things happen to the raw bytes delivered by the
terminal emulator. For example, when you press <Return> which sends byte 13, in
cooked mode, this is converted the a newline (byte 10) for receipt by the
program. Also in cooked mode, backspace (or DEL, depends, see "stty -a") is
handled by the line disciple: your program sees the text as it was _after_ you
did all the backspacing. And so forth.
Perhaps the Windows console is treating ESC specially, apparently as "line
erase", discarduing any preceeding text. Hence your results.
On a UNIX program the normal thing would be to either to:
- accept this, and use the liternal-next kestroke (usually ^V) to tell it not
to the bytes special to the line discipline. So you might type ^V^H to get a
literal ^H code in your input and so forth.
- use termios to turn off all the control keystrokes (erase, kill and so forth)
- put the terminal into "raw" mode where keystroke bytes are sent through
unchanged (although them you need to hand carriage return yourself, etc)
Perhaps Windows has a "literal-next" keystroke line UNIX does.
I have a multi-threaded Python program which recognizes ESC as
a command to stop something. This works on Linux, but not on
Windows. Apparently something in Windows land pulls in "readline".
Unlikely. See above.
What's the best way to get input from the console (not any
enclosing shell script) that's cross-platform, cross-version
(Python 2.7, 3.x), and doesn't do "readline" processing?
sys.stdin.readline()
input() is a conveience function, now very low level.
Cheers,
Cameron Simpson <c...@zip.com.au>
--
https://mail.python.org/mailman/listinfo/python-list
