Rob Landley is right [1]—terminal control is obsolete. Precious few [2] have actual terminals, and those of us who still use command line interfaces are using software programs that emulate physical devices talking to other software programs that emulate physical devices. Furthermore, all those software programs emulating physical devices have pretty much converged on using ANSI (American National Standards Institute) terminal control codes [3], so much of the reason for termcap [4] has gone away.
So now it should be a simple matter to look up ANSI terminal control codes to see what to send to scroll the screen to the left, right?
Yeah [5] …
And lest you think that page on xterm control codes is intentionally incomprehensible, it's not. Well, it is incomprehensible, and it may be intentional, bit it's not alone. They are all [6] pretty abysmal [7]. And they're all pretty abysmal because the actual standard, ECMA-48 [8], is pretty abysmal as standards go.
Here's a representative sample:
## 5.3 Elements of the C1 set
These control functions are represented
a) in a 7-bit code by 2-character escape sequences of the form ESC Fe, where ESC is represented by bit combination 01/11 and Fe is represented by a bit combination from 04/00 to 05/15;
b) in an 8-bit code by bit combinations from 08/00 to 09/15; however, when the announcer sequence ESC 02/00 04/06 according to Standard ECMA (European Computer Manufacturers Association)-35 is used, the control functions of the C1 set are represented by ESC Fe sequences as in a 7-bit code.
and here's a translation into more modern terminology:
## 5.3 Elements of the extended ASCII control set
These control functions are represented
a) in a 7-bit code by a 2-character escape sequence of the form <ESC> <Fe>, where <ESC> is ASCII character 0x1B and <Fe> is ASCII characters 0x40 ('@') through 0x5F ('_');
b) in an 8-bit code by byte values between 0x80 and 0x9F; however, when the sequence <ESC> ‘ ’ ‘F’ (0x1B 0x20 0x46) according to Standard ECMA-35 is used, the control functions of the C1 set are represented by <ESC> <Fe> sequences as in a 7-bit code.
Yes, the ECMA standards represent characters using a (to me) bizarre column-based format which are kind of hexadecimalesque (4/13 is column 4, row 13) without being actual hexadecimal (0x4D), which makes reading the standard a bit more difficult. It was only reading these [9] old [10] standards [11] in conjunction with this page [12] did is start making a bit of sense.
For instance, on the xterm reference page [13], there's the sequence “APC Pt ST” but it's never defined what APC or ST actually are, but Pt is defined to be `printable text.” It's only by reading the other documentation closely that you realize that the sequence will either be
0x9F <printable text> 0x9C
or
0x1B ‘_’ <printable text> 0x1B ‘\’
Which is beside the point, because xterm will ignore such sequences anyway.
Sigh.
The sequences themselves are pretty simple; it's just the presentation that universally sucks (and all the presentations except the ECMA-48 one assume you have read and understand the ECMA-48 standard).
[1] http://landley.net/notes-2015.html#27-04-2015
[2] http://www.classiccmp.org/
[3] https://en.wikipedia.org/wiki/ANSI_escape_code
[4] https://en.wikipedia.org/wiki/Termcap
[5] http://www.xfree86.org/4.7.0/ctlseqs.html
[6] http://paulbourke.net/dataformats/ascii/
[7] http://sydney.edu.au/engineering/it/~tapted/ansi.html
[8] http://www.ecma-international.org/publications/standards/Ecma-048.htm
[9] http://www.ecma-international.org/publications/standards/Ecma-048.htm
[10] http://paulbourke.net/dataformats/ascii/
[11] http://sydney.edu.au/engineering/it/~tapted/ansi.html
[12] http://www.inwap.com/pdp10/ansicode.txt