If you take a look at the ANSI ASCII standard, the lower part of the character set (the first 32) are reserved "control characters" (sometimes referred to as "escape sequences"). These are things like the NUL character, Life Feed, Carriage Return, Tab, Bell, etc. The vast majority can be emulated by pressing the Ctrl key in combination with another key.
The 27th (decimal) or \033
octal sequence, or 0x1b
hex sequence is the Escape sequence. They are all representations of the same control sequence. Different shells, languages and tools refer to this sequence in different ways. Its Ctrl sequence is Ctrl-[, hence sometimes being represented as ^[
, ^
being a short hand for Ctrl.
You can enter control character sequences as a raw sequences on your command line by proceeding them with Ctrl-v. Ctrl-v to most shells and programs stops the interpretation of the following key sequence and instead inserts in its raw form. If you do this with either the Escape key or Ctrl-v it will display on most shells as ^[
. However although this sequence will get interpreted, it will not cut and paste easily, and may get reduced to a non control character sequence when encountered by certain protocols or programs.
To get around this to make it easier to use, certain utilities represent the "raw" sequence either with \033
(by octal reference), hex reference \x1b
or by special character reference \e
. This is much the same in the way that \t
is interpreted as a Tab - which by the way can also be input via Ctrl-i, or \n
as newline or the Enter key, which can also be input via Ctrl-m.
So when Gilles says:
27 = 033 = 0x1b = ^[ = \e
He is saying decimal ASCII 27, octal 33, hex 1b, Ctrl-[ and \e
are
all equal he means they all refer to the same thing (semantically).
When Demizey says
^[ is just a representation of ESCAPE and \e is interpreted as an actual ESCAPE character
He means semantically, but if you press Ctrl-v Ctrl-[ this is exactly the same as \e
, the raw inserted sequence will most likely be treated the same way, but this is not always guaranteed, and so it recommended to use the programmatically more portable \e
or 0x1b
or \033
depending on the language/shell/utility being used.
In its default configuration, PuTTY sends cursor keys in normal mode, e.g., ^[OA
while screen sets the cursor keys to application mode, e.g., ^[[A
.
That is done by screen's sending the escape sequence to turn on the keypad (in termcap ks
, terminfo smkx
). That happens to turn on the application mode for both the numeric keypad and the cursor keys, because both are present in the ks/smkx
capability. screen uses this capability if it is present, when initializing the terminal. screen also follows up by sending the string in the termcap CS
capability if it is set, hinting that the original design was to use terminal descriptions where only the keypad was initialized by ks/smkx
.
You notice this difference because your key bindings expect the strings sent by the cursor keys in normal mode. If you modified the terminal description for screen to omit the part which changes the cursor keys, you could continue to use those bindings.
For instance, you could do this:
infocmp screen >foo
vi foo
and change the assignment
smkx=\E[?1h\E=,
to
smkx=\E=,
then
tic foo
to compile the modified description. If you do this as your (non-root) user, tic will put the compiled description in your ~/.terminfo
directory. There are drawbacks to this approach, and using tput
to obtain key-binding information is preferable. But it is simple.
Further reading:
Best Answer
There is no scheme,
screen
, like any terminal application, doesn't deal with keystrokes, but with characters or sequences of characters which it reads from a terminal device.It's the terminal (or terminal emulator like
xterm
) that transforms a keystroke into a character or sequence of characters which it sends over a wire (the wire being virtual in the case of a terminal emulator) to the system. The line discipline of the terminal device may do some modification on that (for instance, CRs turned into LFs).To know what character or character sequence
screen
receives when you type something on your terminal, you can use for instanceod
to display them for you.For instance, if I enter
od -tc
in a terminal,od -tc
will read characters from the terminal device, and display them on stdout (the terminal device as well if you've not redirected the output) in a printable way.For instance, here's the output when I type: Up Enter Ctrl+D (the latter to signify
od
the end of input):Up has sent the 3 characters ESC,
[
andA
, and the\r
has been changed to a\n
.screen
will actually set its host terminal in raw mode so that no transformation is done by the line discipline and no characters are treated specially (like the004
character sent upon Ctrl+D above for instance).To see what the terminal sends in that mode, you'd do:
Notice how the
\n
output byod
has not been converted to\r\n
for output (\n
is line-feed, when output to a terminal, it only moved the cursor down, not to the beginning of the line for which your need a carriage return (\r
)).Above, we're setting the terminal in raw mode, but also set it so that a
read
on the terminal device times out after 10 hundredths of second as soon as1
character has been received (because otherwise, we'd have to type a lot of characters before theread
done byod
returns).Pressing Tab on all terminals sends the TAB ASCII character also known as
\t
or^I
orC-I
or\011
. For Shift+Tab, not all terminals send the same thing (some sendESC
[
Z
, some send\t
as well and some send nothing for instance).The terminfo database can tell you what that character is for a given terminal (based on the
$TERM
variable) via thekcbt
capability (back tab, not necessarily sent upon Shift-Tab though).For the current terminal: