Wait for a keypress before continuing?

Nobody nobody at nowhere.com
Thu Aug 18 13:58:41 EDT 2011

On Thu, 18 Aug 2011 01:24:30 -0700, peter wrote:

> This is very similar to my solution, which was to use stty turn off
> keyboard echo, then repeatedly read sys.stdin.read(1) until a unique
> keystroke had been defined. For example, the 'Insert' key seems to
> return a sequence of four codes, namely 27, 91, 50, 126.  It works but
> has two disadvantages which I have managed to live with:-
> 1. As character 27 is used to signal the start of a 'special' key
> sequence, it cannot detect a single press of the Esc key. The
> workaround is to detect a double press instead.
> 2. Some keys seem to return different sets of codes depending on the
> circumstances.  For example, F1 returns 27,91,91,65 from the command
> line, and 27,79,80 from a GUI window. I suspect there may be
> variations between flavours of Linux too. The solution is to detect
> all possibilities - so far I haven't found any overlaps.

Escape sequences vary between terminals. A given key may have different
escape sequences on the Linux console, xterm, a vt220, etc. The
termcap and terminfo databases exist for this purpose (terminfo is newer).

Some escape sequences vary by "mode". E.g. the cursor keys typically
produce different sequences depending upon whether the terminal is in
"keypad" mode.

The normal solution for distinguishing the escape key from an escape
sequence is a timeout. Unfortunately, it needs to be quite long in order
to reliably support network (ssh, telnet, etc) connections.

> Not pretty, but as I said it works. I know now not to spend time
> looking further. Whilst there may be a historical reason for the
> current situation, it would be a great convenience for amateur coders
> like mayself if the gurus could devise a platform independent version
> of mscvrt.

The platform-independent high-level terminal interface is called "curses".

More information about the Python-list mailing list