[haiku-development] Re: Terminal escape codes
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 20 Apr 2012 17:26:41 +0200
On 2012-04-19 at 20:22:30 [+0200], Donn Cave <donn@xxxxxxxxxxx> wrote:
> Adrien Destugues wrote:
> > arfonzo is currently trying to improve Terminal compatibility with various
> > BBS. He noticed that the escape sequences for arrows are now ESC + O +
> > ABCD instead of the usual ANSI ESC + [ + ABCD.
> ...
> > Is there any problem reverting to the ANSI escape code for moving cursor ?
>
> Note that we could be talking about two different things here, because
> a cursor and a cursor key are two very different things:
> 1. the escape sequence sent to the TTY device when you press a cursor key
> 2. the escape sequence that causes the cursor to move when received
> from the TTY.
That is correct, though a bit confusing, since it is observed from the
terminal's point of view (and the order of the points doesn't match the order
in the introducing sentence). From a command line application point of view:
1. When a cursor key is pressed, the application receives an escape sequence
(more correctly: control sequence) from the terminal.
2. When the application wants to move the cursor in the terminal, it has to
send a certain control sequence to the terminal.
> For the cursor keys, both <esc>[A and <esc>OA etc. are correct, depending
> on the current mode. Past that, I am a little fuzzy - by some accounts,
> this is the `application keypad mode' setting that also turns the numeric
> keypad into function & arrow keys. I am not sure that's right (though may
> be widely implemented anyway), and there may be another mode involved.
Just checked the VT100 and VT420 manuals and you are correct. The two modes
are "ANSI Mode and Cursor Key Mode Reset" vs. "... Cursor Key Mode Set" (the
naming differs in the VT420 manual). There's also VT52 Mode ("ESC A"), though
that probably isn't relevant anymore.
> Cursor movement is <esc>[A etc.
Indeed.
Anyway, how things (should) work in practice is that command line
applications don't hardcode either kind of sequence. They should use the TERM
environment variable to identify the terminal and interpret/use sequences
matching the ones for that respective terminal. There are several mechanism
which help with that. The oldest (?) and still used one is termcap (cf.
/etc/termcap). There's terminfo which AFAIK is used (compiled into?) ncurses.
There's the inputrc, which is used by the readline library -- which also uses
termcap -- to map sequences sent by the terminal to commands.
Interestingly for terminal type "ansi" termcap defines "ku=\E[A" (meaning
"cursor key up" is "ESC [ A"), but for terminal type "xterm" it is "ku=\EOA"
("ESC O A"). So strictly speaking a terminal that identifies itself as
"xterm" (like Haiku's Terminal) should send "ESC O A" or applications that
use termcap only won't interpret the cursor key up sequence correctly.
However, in openSuse 11.4 /etc/inputrc maps both sequences to
"previous-history", so applications using readline work fine in either case.
To sum this up, even though it breaks termcap-only appplications (which may
not exist in practice anymore), changing the cursor key sequences to match
the Unix xterm-like terminals (particularly the xterm application) probably
does make sense, but inputrc needs to be adjusted. What I wrote in my
previous mail was a bit ambiguous: termcap must not be adjusted in the same
sense. It can be updated to a new version (should there be one), though I
doubt that this changes anything in this respect. The same holds true for
ncurses I guess.
CU, Ingo
Other related posts:
