CODEWITHSUNDEEP
pythonansi-escapepython-cursesterminfo
Marcin
Marcin

Reputation: 917

rxvt ignoring DECCKM sequence

I'm writing a CLI server. In my project I do the following (simplification):

curses.setupterm("rxvt")
smkx = curses.tigetstr("smkx")
write_to_terminal_client(smkx)

The detected smkx sequence is only "\E=" which matches the "infocmp rxvt" (a poor terminfo entry?).

Now when I run my CLI server and connect to it with a telnet run on a rxvt terminal, the terminal receives the smkx sequence. When the user on the rxvt terminal presses a left-arrow key I would expect "\E[D" sequence be sent to the CLI server (since the application mode has been set). Unfortunately the sequence is always "\EOD" both when the smkx sequence has and has not been sent to the terminal client.

I tried hardcoding the smkx sequence to "\E[?1h\E=" and sending this to client, but it did not change anything.

Also the terminal does not respond to the DECRQM query.

My full picture is that my application learns the name of terminal and queries the terminfo database for key codes and other capabilities. I'm running ubuntu 13.10. Rxvt terminal is "2.7.10"

The questions:

  1. Am I doing anything wrong?
  2. If not, how should I understand smkx="\E=" and not "\E[?1h\E=" (DECCKM not supported?)
  3. How to properly detect such situations and deal with them (fallback to a ANSI cursor sequences?)

Regards

Upvotes: 0

Views: 193

Answers (1)

Thomas Dickey
Thomas Dickey

Reputation: 54563

The problem appears to be that your program is sending smkx (good) but assuming that it knows the strings which will be sent for various special keys (not good). In a properly constructed terminal description, the special keys also are listed (see terminfo(5)):

  key_up                    kcuu1  ku   up-arrow key
  key_down                  kcud1  kd   down-arrow key
  key_left                  kcub1  kl   left-arrow key
  key_right                 kcuf1  kr   right-arrow key

So, rather than looking for \E[D, your program should look for whatever tigetstr says is the string for kcub1.

Regarding DECRQM, rxvt may not implement that because it is not a "VT100" control sequence. Referring to XTerm Control Sequences, that is "For VT300 and up", while rxvt's manual page says "vt102 terminal".

While there are occasional problems reported, the terminal database largely reflects tradeoffs between users' conventions and the actual terminal capabilities. Some users (in particular Linux users with bash) prefer not to use the terminal's application mode. Outside of that niche, longstanding convention has been to use the application mode. The xterm manual provides additional discussion on this topic.

In ncurses, the infocmp command has a feature (option -i) which lets you see (more) clearly the effect of the initialization strings. It does not decompose rmkx/smkx, but that is added easily. Doing that, it would report for rxvt:

is1: {DEC-47}{DECPAM}{DEC-CKM}
is2: {RSR}{SGR0}\E[2J{home}{DEC+AWM}{DEC-CKM;COLM;SCLM;OM}{rmir}
rs1: {rmkx}{ECMA-1;3;IRM;5;6}{DEC+AWM}{SGR0}{RSR}\E[2J{home}
rs2: {is2}{rmkx}{DEC-1000}{cnorm}
smcup: {sc}{DEC+47}
rmcup: \E[2J{DEC-47}{rc}
smkx: {DECPAM}
rmkx: {DECPNM}

and xterm:

is2: \E[!p{DEC-COLM;SCLM}{rmir}{DECPNM}
rs1: {RIS}
rs2: {is2}
smcup: {DEC+1049}
rmcup: {DEC-1049}
smkx: {DEC+CKM}{DECPAM}
rmkx: {DEC-CKM}{DECPNM}

That is, the terminal description for xterm turns DECCKM (cursor keys) on/off with smkx/rmkx, while that for rxvt does not. Additionally, rxvt's initialization string turns DECCKM off.

Upvotes: 1

Related Questions