Hubbry Logo
ANSI escape codeANSI escape codeMain
Open search
ANSI escape code
Community hub
ANSI escape code
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
ANSI escape code
ANSI escape code
from Wikipedia

ANSI X3.64 (ISO/IEC 6429)
Output of the system-monitor htop, an ncurses-application (which uses SGR and other ANSI/ISO control sequences).
Standard
ClassificationISO/IEC 2022 based control code and control sequence set
Other related encodings

Other control function standards:

ANSI escape sequences are a standard for in-band signaling to control cursor location, color, font styling, and other options on video text terminals and terminal emulators. Certain sequences of bytes, most starting with an ASCII escape character and a bracket character, are embedded into text. The terminal interprets these sequences as commands, rather than text to display verbatim.

ANSI sequences were introduced in the 1970s to replace vendor-specific sequences and became widespread in the computer equipment market by the early 1980s. Although hardware text terminals have become increasingly rare in the 21st century, the relevance of the ANSI standard persists because a great majority of terminal emulators and command consoles interpret at least a portion of the ANSI standard.

History

[edit]

Almost all manufacturers of video terminals added vendor-specific escape sequences to perform operations such as placing the cursor at arbitrary positions on the screen. One example is the VT52 terminal, which allowed the cursor to be placed at an x,y location on the screen by sending the ESC character, a Y character, and then two characters representing numerical values equal to the x,y location plus 32 (thus starting at the ASCII space character and avoiding the control characters). The Hazeltine 1500 had a similar feature, invoked using ~, DC1 and then the X and Y positions separated with a comma. While the two terminals had identical functionality in this regard, different control sequences had to be used to invoke them.

As these sequences were different for different terminals, elaborate libraries such as termcap ("terminal capabilities") and utilities such as tput had to be created so programs could use the same API to work with any terminal. In addition, many of these terminals required sending numbers (such as row and column) as the binary values of the characters; for some programming languages, and for systems that did not use ASCII internally, it was often difficult to turn a number into the correct character.

The ANSI standard attempted to address these problems by making a command set that all terminals would use and requiring all numeric information to be transmitted as ASCII numbers. The first standard in the series was ECMA-48, adopted in 1976.[1] It was a continuation of a series of character coding standards, the first one being ECMA-6 from 1965, a 7-bit standard from which ISO 646 originates. The name "ANSI escape sequence" dates from 1979 when ANSI adopted ANSI X3.64. The ANSI X3L2 committee collaborated with the ECMA committee TC 1 to produce nearly identical standards. These two standards were merged into an international standard, ISO 6429.[1] In 1994, ANSI withdrew its standard in favor of the international standard.

DEC VT100 terminal
The DEC VT100 video display terminal.

The first popular video terminal to support these sequences was the Digital VT100, introduced in 1978.[2] This model was very successful in the market, which sparked a variety of VT100 clones, among the earliest and most popular of which was the much more affordable Zenith Z-19 in 1979.[3] Others included the Qume QVT-108, Televideo TVI-970, Wyse WY-99GT as well as optional "VT100" or "VT103" or "ANSI" modes with varying degrees of compatibility on many other brands. The popularity of these gradually led to more and more software (especially bulletin board systems and other online services) assuming the escape sequences worked, leading to almost all new terminals and emulator programs supporting them.

In 1981, ANSI X3.64 was adopted for use in the US government by FIPS publication 86. Later, the US government stopped duplicating industry standards, so FIPS pub. 86 was withdrawn.[4]

ECMA-48 has been updated several times and is currently at its 5th edition, from 1991.[5] It is also adopted by ISO and IEC as standard ISO/IEC 6429.[6] A version is adopted as a Japanese Industrial Standard, as JIS X 0211.

Related standards include ITU T.61, the Teletex standard, and the ISO/IEC 8613, the Open Document Architecture standard (mainly ISO/IEC 8613-6 or ITU T.416). The two systems share many escape codes with the ANSI system, with extensions that are not necessarily meaningful to computer terminals. Both systems quickly fell into disuse, but ECMA-48 does mark the extensions used in them as reserved.

Platform support

[edit]
Xterm terminal emulator
The Xterm terminal emulator.

In the early 1980s, large amounts of software directly used these sequences to update screen displays. This included everything on VMS (which assumed DEC terminals), most software designed to be portable on CP/M home computers, and even lots of Unix software as it was easier to use than the termcap libraries, such as the shell script examples below in this article.

Terminal emulators for communicating with remote machines almost always implement ANSI escape codes. This includes anything written to communicate with bulletin-board systems on home and personal computers. On Unix terminal emulators such as xterm also can communicate with software running on the same machine, and thus software running in X11 under a terminal emulator could assume the ability to write these sequences.

As computers got more powerful even built-in displays started supporting them, allowing software to be portable between CP/M systems. There were attempts to extend the escape sequences to support printers[7] and as an early PDF-like document storage format, the Open Document Architecture.[citation needed]

DOS and Windows

[edit]

The IBM PC, introduced in 1981, did not support these or any other escape sequences for updating the screen. Only a few control characters (BEL, CR, LF, BS) were interpreted by the underlying BIOS. Any display effects had to be done with BIOS calls, which were notoriously slow, or by directly manipulating the IBM PC hardware. This made any interesting software non-portable and led to the need to duplicate details of the display hardware in PC Clones.

DOS version 2.0 included an optional device driver named ANSI.SYS. Poor performance, and the fact that it was not installed by default, meant software rarely (if ever) took advantage of it.

The Windows Console did not support ANSI escape sequences, nor did Microsoft provide any method to enable them. Some replacements such as JP Software's TCC (formerly 4NT), Michael J. Mefford's ANSI.COM, Jason Hood's ANSICON[8] and Maximus5's ConEmu enabled ANSI escape sequences. Software such as the Python colorama package[9] or Cygwin modified text in-process as it was sent to the console, extracting the ANSI Escape sequences and emulating them with Windows calls.

In 2016, Microsoft released the Windows 10 version 1511 update which unexpectedly implemented support for ANSI escape sequences, over three decades after the debut of Windows.[10] This was done alongside Windows Subsystem for Linux, apparently to allow Unix-like terminal-based software to use the Windows Console. Windows PowerShell 5.1 enabled this by default, and PowerShell 6 made it possible to embed the necessary ESC character into a string with `e.[11]

Windows Terminal, introduced in 2019, supports the sequences by default.[12] Since Windows 11 22H2 and Windows Terminal 1.15, Windows Terminal replaces Windows Console as the default.[13][14]

C0 control codes

[edit]

Almost all users assume some functions of some single-byte characters. Initially defined as part of ASCII, the default C0 control code set is now defined in ISO 6429 (ECMA-48), making it part of the same standard as the C1 set invoked by the ANSI escape sequences (although ISO 2022 allows the ISO 6429 C0 set to be used without the ISO 6429 C1 set, and vice versa, provided that 0x1B is always ESC). This is used to shorten the amount of data transmitted, or to perform some functions that are unavailable from escape sequences:

Popular C0 control codes (not an exhaustive list)
^ C0 Abbr C escape sequence Name Effect
^G 0x07 BEL \a Bell Makes an audible noise.
^H 0x08 BS \b Backspace Moves the cursor left (but may "backwards wrap" if cursor is at start of line).
^I 0x09 HT \t Tab Moves the cursor right to next tab stop.
^J 0x0A LF \n Line Feed Moves to next line, scrolls the display up if at bottom of the screen. Usually does not move horizontally, though programs should not rely on this.
^L 0x0C FF \f Form Feed Move a printer to top of next page. Usually does not move horizontally, though programs should not rely on this. Effect on video terminals varies.
^M 0x0D CR \r Carriage Return Moves the cursor to column zero.
^[ 0x1B ESC \x1B, \033 Escape Starts all the escape sequences

Escape sequences vary in length. The general format for an ANSI-compliant escape sequence is defined by ANSI X3.41 (equivalent to ECMA-35 or ISO/IEC 2022).[15]: 13.1  The escape sequences consist only of bytes in the range 0x20—0x7F (all the non-control ASCII characters), and can be parsed without looking ahead. The behavior when a control character, a byte with the high bit set, or a byte that is not part of any valid sequence, is encountered before the end is undefined.

Fe Escape sequences

[edit]

If the ESC is followed by a byte in the range 0x40 to 0x5F, the escape sequence is of type Fe. Its interpretation is delegated to the applicable C1 control code standard.[15]: 13.2.1  Accordingly, all escape sequences corresponding to C1 control codes from ANSI X3.64 / ECMA-48 follow this format.[16]: 5.3.a 

The standard says that, in 8-bit environments, the control functions corresponding to type Fe escape sequences (those from the set of C1 control codes) can be represented as single bytes in the 0x80–0x9F range.[16]: 5.3.b  This is possible in character encodings conforming to the provisions for an 8-bit code made in ISO 2022, such as the ISO 8859 series. However, in character encodings used on modern devices such as UTF-8 or CP-1252, those codes are often used for other purposes, so only the 2-byte sequence is typically used. In the case of UTF-8, representing a C1 control code via the C1 Controls and Latin-1 Supplement block results in a different two-byte code (e.g. 0xC2,0x8E for U+008E), but no space is saved this way.

Some type Fe (C1 set element) ANSI escape sequences (not an exhaustive list)
Code C1 Abbr Name Effect
ESC N 0x8E SS2 Single Shift Two Select a single character from one of the alternative character sets. SS2 selects the G2 character set, and SS3 selects the G3 character set.[17] In a 7-bit environment, this is followed by one or more GL bytes (0x20–0x7F) specifying a character from that set.[15]: 9.4  In an 8-bit environment, these may instead be GR bytes (0xA0–0xFF).[15]: 8.4 
ESC O 0x8F SS3 Single Shift Three
ESC P 0x90 DCS Device Control String Terminated by ST.[16]: 5.6  Xterm's uses of this sequence include defining User-Defined Keys, and requesting or setting Termcap/Terminfo data.[17]
ESC [ 0x9B CSI Control Sequence Introducer Starts most of the useful sequences, terminated by a byte in the range 0x40 through 0x7E.[16]: 5.4 
ESC \ 0x9C ST String Terminator Terminates strings in other controls.[16]: 8.3.143 
ESC ] 0x9D OSC Operating System Command Starts a control string for the operating system to use, terminated by ST.[16]: 8.3.89 
ESC X 0x98 SOS Start of String Takes an argument of a string of text, terminated by ST.[16]: 5.6  The uses for these string control sequences are defined by the application[16]: 8.3.2, 8.3.128  or privacy discipline.[16]: 8.3.94  These functions are rarely implemented and the arguments are ignored by xterm.[17] Some Kermit clients allow the server to automatically execute Kermit commands on the client by embedding them in APC sequences; this is a potential security risk if the server is untrusted.[18]
ESC ^ 0x9E PM Privacy Message
ESC _ 0x9F APC Application Program Command

Control Sequence Introducer commands

[edit]

For Control Sequence Introducer, or CSI, commands, the ESC [ (written as \e[, \x1b[ or \033[ in several programming languages) is followed by any number (including none) of "parameter bytes" in the range 0x30–0x3F (ASCII 0–9:;<=>?), then by any number of "intermediate bytes" in the range 0x20–0x2F (ASCII space and !"#$%&'()*+,-./), then finally by a single "final byte" in the range 0x40–0x7E (ASCII @A–Z[\]^_`a–z{|}~).[16]: 5.4 

All common sequences just use the parameters as a series of semicolon-separated numbers such as 1;2;3.[16]: 5.4.2  Missing numbers are treated as 0 (1;;3 acts like the middle number is 0, and no parameters at all in ESC[m acts like a 0 reset code). Some sequences (such as CUU) treat 0 as 1 in order to make missing parameters useful.[16]: F.4.2 

A subset of arrangements was declared "private" so that terminal manufacturers could insert their own sequences without conflicting with the standard. Sequences containing the parameter bytes <=>? or the final bytes 0x70–0x7E (p–z{|}~) are private.

The behavior of the terminal is undefined in the case where a CSI sequence contains any character outside of the range 0x20–0x7E. These illegal characters are either C0 control characters (the range 0–0x1F), DEL (0x7F), or bytes with the high bit set. Possible responses are to ignore the byte, to process it immediately, and furthermore whether to continue with the CSI sequence, to abort it immediately, or to ignore the rest of it.[citation needed]

Some ANSI control sequences (not an exhaustive list)
Code[a] Abbr Name Effect
CSI n A CUU Cursor Up Moves the cursor n (default 1) cells in the given direction. If the cursor is already at the edge of the screen, this has no effect.
CSI n B CUD Cursor Down
CSI n C CUF Cursor Forward
CSI n D CUB Cursor Back
CSI n E CNL Cursor Next Line Moves cursor to beginning of the line n (default 1) lines down. (not ANSI.SYS)
CSI n F CPL Cursor Previous Line Moves cursor to beginning of the line n (default 1) lines up. (not ANSI.SYS)
CSI n G CHA Cursor Horizontal Absolute Moves the cursor to column n (default 1). (not ANSI.SYS)
CSI n ; m H CUP Cursor Position Moves the cursor to row n, column m. The values are 1-based, and default to 1 (top left corner) if omitted. A sequence such as CSI ;5H is a synonym for CSI 1;5H as well as CSI 17;H is the same as CSI 17H and CSI 17;1H
CSI n J ED Erase in Display Clears part of the screen. If n is 0 (or missing), clear from cursor to end of screen. If n is 1, clear from cursor to beginning of the screen. If n is 2, clear entire screen (and moves cursor to upper left on DOS ANSI.SYS). If n is 3, clear entire screen and delete all lines saved in the scrollback buffer (this feature was added for xterm and is supported by other terminal applications).
CSI n K EL Erase in Line Erases part of the line. If n is 0 (or missing), clear from cursor to the end of the line. If n is 1, clear from cursor to beginning of the line. If n is 2, clear entire line. Cursor position does not change.
CSI n S SU Scroll Up Scroll whole page up by n (default 1) lines. New lines are added at the bottom. (not ANSI.SYS)
CSI n T SD Scroll Down Scroll whole page down by n (default 1) lines. New lines are added at the top. (not ANSI.SYS)
CSI n ; m f HVP Horizontal Vertical Position Same as CUP, but counts as a format effector function (like CR or LF) rather than an editor function (like CUD or CNL). This can lead to different handling in certain terminal modes.[16]: Annex A 
CSI n m SGR Select Graphic Rendition Sets colors and style of the characters following this code
CSI 5i AUX Port On Enable aux serial port usually for local serial printer
CSI 4i AUX Port Off Disable aux serial port usually for local serial printer

CSI 6n DSR Device Status Report Reports the cursor position (CPR) by transmitting ESC[n;mR, where n is the row and m is the column.
Some popular private sequences
Code Abbr Name Effect
CSI s SCP, SCOSC Save Current Cursor Position Saves the cursor position/state in SCO console mode.[19] In vertical split screen mode, instead used to set (as CSI n ; n s) or reset left and right margins.[20]
CSI u RCP, SCORC Restore Saved Cursor Position Restores the cursor position/state in SCO console mode.[21]
CSI ? 25 h DECTCEM Shows the cursor, from the VT220.
CSI ? 25 l DECTCEM Hides the cursor.
CSI ? 1004 h Enable reporting focus. Reports whenever terminal emulator enters or exits focus as ESC [I and ESC [O, respectively.
CSI ? 1004 l Disable reporting focus.
CSI ? 1049 h Enable alternative screen buffer, from xterm
CSI ? 1049 l Disable alternative screen buffer, from xterm
CSI ? 2004 h Turn on bracketed paste mode.[22] In bracketed paste mode, text pasted into the terminal will be surrounded by ESC [200~ and ESC [201~; programs running in the terminal should not treat characters bracketed by those sequences as commands (Vim, for example, does not treat them as commands).[23] From xterm[24]
CSI ? 2004 l Turn off bracketed paste mode.

Select Graphic Rendition parameters

[edit]

The control sequence CSI n m, named Select Graphic Rendition (SGR), sets display attributes. Several attributes can be set in the same sequence, separated by semicolons.[25] Each display attribute remains in effect until a following occurrence of SGR resets it.[16] If no codes are given, CSI m is treated as CSI 0 m (reset / normal).

n Name Note
0 Reset or normal All attributes become turned off
1 Bold or increased intensity As with faint, the color change is a PC (SCO / CGA) invention.[26][better source needed]
2 Faint, decreased intensity, or dim May be implemented as a light font weight like bold.[27]
3 Italic Not widely supported. Sometimes treated as inverse or blink.[26]
4 Underline Style extensions exist for Kitty, VTE, mintty, iTerm2 and Konsole.[28][29][30]
5 Slow blink Sets blinking to less than 150 times per minute
6 Rapid blink MS-DOS ANSI.SYS, 150+ per minute; not widely supported
7 Reverse video or invert Swap foreground and background colors; inconsistent emulation[31][dubiousdiscuss]
8 Conceal or hide Not widely supported.
9 Crossed-out, or strike Characters legible but marked as if for deletion. Not supported in Terminal.app.
10 Primary (default) font
11–19 Alternative font Select alternative font n − 10
20 Fraktur (Gothic) Rarely supported
21 Doubly underlined; or: not bold Double-underline per ECMA-48,[16]: 8.3.117  but instead disables bold intensity on several terminals, including in the Linux kernel's console before version 4.17.[32]
22 Normal intensity Neither bold nor faint; color changes where intensity is implemented as such.
23 Neither italic, nor blackletter
24 Not underlined Neither singly nor doubly underlined
25 Not blinking Turn blinking off
26 Proportional spacing ITU T.61 and T.416, not known to be used on terminals
27 Not reversed
28 Reveal Not concealed
29 Not crossed out
30–37 Set foreground color
38 Set foreground color Next arguments are 5;n or 2;r;g;b
39 Default foreground color Implementation defined (according to standard)
40–47 Set background color
48 Set background color Next arguments are 5;n or 2;r;g;b
49 Default background color Implementation defined (according to standard)
50 Disable proportional spacing T.61 and T.416
51 Framed Implemented as "emoji variation selector" in mintty.[33]
52 Encircled
53 Overlined Not supported in Terminal.app
54 Neither framed nor encircled
55 Not overlined
58 Set underline color Not in standard; implemented in Kitty, VTE, mintty, and iTerm2.[28][29] Next arguments are 5;n or 2;r;g;b.
59 Default underline color Not in standard; implemented in Kitty, VTE, mintty, and iTerm2.[28][29]
60 Ideogram underline or right side line Rarely supported
61 Ideogram double underline, or double line on the right side
62 Ideogram overline or left side line
63 Ideogram double overline, or double line on the left side
64 Ideogram stress marking
65 No ideogram attributes Reset the effects of all of 6064
73 Superscript Implemented only in mintty[33]
74 Subscript
75 Neither superscript nor subscript
90–97 Set bright foreground color Not in standard; originally implemented by aixterm[17]
100–107 Set bright background color

Colors

[edit]

3-bit and 4-bit

[edit]

The original specification only had 8 colors, and just gave them names. The SGR parameters 30–37 selected the foreground color, while 40–47 selected the background. Quite a few terminals implemented "bold" (SGR code 1) as a brighter color rather than a different font, thus providing 8 additional foreground colors. Usually you could not get these as background colors, though sometimes inverse video (SGR code 7) would allow that. Examples: to get black letters on white background use ESC[30;47m, to get red use ESC[31m, to get bright red use ESC[1;31m. To reset colors to their defaults, use ESC[39;49m (not supported on some terminals), or reset all attributes with ESC[0m. Later terminals added the ability to directly specify the "bright" colors with 90–97 and 100–107.

The chart below shows a few examples of how classical standards and modern terminal emulators translate the 4-bit color codes into 24-bit color codes.

FG BG Name CGA/EGA/VGA Windows Console[b] Windows
PowerShell&
1.0–6.0
[c]
Visual Studio Code[d] Windows 10
Console
[e]
Terminal.app PuTTY mIRC xterm Ubuntu[f] Eclipse Terminal
30 40 Black 0, 0, 0 12, 12, 12 0, 0, 0 1, 1, 1 0, 0, 0
31 41 Red 170, 0, 0 128, 0, 0 205, 49, 49 197, 15, 31 153, 0, 0 187, 0, 0 127, 0, 0 205, 0, 0 222, 56, 43 205, 0, 0
32 42 Green 0, 170, 0 0, 128, 0 13, 188, 121 19, 161, 14 0, 166, 0 0, 187, 0 0, 147, 0 0, 205, 0 57, 181, 74 0, 205, 0
33 43 Yellow 170, 85, 0 128, 128, 0 238, 237, 240 229, 229, 16 193, 156, 0 153, 153, 0 187, 187, 0 252, 127, 0 205, 205, 0 255, 199, 6 205, 205, 0
34 44 Blue 0, 0, 170 0, 0, 128 36, 114, 200 0, 55, 218 0, 0, 178 0, 0, 187 0, 0, 127 0, 0, 238[35] 0, 111, 184 0, 0, 238
35 45 Magenta 170, 0, 170 128, 0, 128 1, 36, 86 188, 63, 188 136, 23, 152 178, 0, 178 187, 0, 187 156, 0, 156 205, 0, 205 118, 38, 113 205, 0, 205
36 46 Cyan 0, 170, 170 0, 128, 128 17, 168, 205 58, 150, 221 0, 166, 178 0, 187, 187 0, 147, 147 0, 205, 205 44, 181, 233 0, 205, 205
37 47 White 170, 170, 170 192, 192, 192 229, 229, 229 204, 204, 204 191, 191, 191 187, 187, 187 210, 210, 210 229, 229, 229 204, 204, 204 229, 229, 229
90 100 Bright Black (Gray) 85, 85, 85 128, 128, 128 102, 102, 102 118, 118, 118 102, 102, 102 85, 85, 85 127, 127, 127 127, 127, 127 128, 128, 128 0, 0, 0
91 101 Bright Red 255, 85, 85 255, 0, 0 241, 76, 76 231, 72, 86 230, 0, 0 255, 85, 85 255, 0, 0
92 102 Bright Green 85, 255, 85 0, 255, 0 35, 209, 139 22, 198, 12 0, 217, 0 85, 255, 85 0, 252, 0 0, 255, 0
93 103 Bright Yellow 255, 255, 85 255, 255, 0 245, 245, 67 249, 241, 165 230, 230, 0 255, 255, 85 255, 255, 0
94 104 Bright Blue 85, 85, 255 0, 0, 255 59, 142, 234 59, 120, 255 0, 0, 255 85, 85, 255 0, 0, 252 92, 92, 255[36] 0, 0, 255 92, 92, 255
95 105 Bright Magenta 255, 85, 255 255, 0, 255 214, 112, 214 180, 0, 158 230, 0, 230 255, 85, 255 255, 0, 255
96 106 Bright Cyan 85, 255, 255 0, 255, 255 41, 184, 219 97, 214, 214 0, 230, 230 85, 255, 255 0, 255, 255
97 107 Bright White 255, 255, 255 229, 229, 229 242, 242, 242 230, 230, 230 255, 255, 255

8-bit

[edit]

As 256-color lookup tables became common on graphic cards, escape sequences were added to select from a pre-defined set of 256 colors:[37]

ESC[38;5;⟨n⟩m Select foreground color      where n is a number from the table below
ESC[48;5;⟨n⟩m Select background color
  0-  7:  standard colors (as in ESC [ 30–37 m)
  8- 15:  high intensity colors (as in ESC [ 90–97 m)
 16-231:  6 × 6 × 6 cube (216 colors): 16 + 36 × r + 6 × g + b (0 ≤ r, g, b ≤ 5)
232-255:  grayscale from dark to light in 24 steps

The colors displayed by these values vary across terminal/emulator implementations as the recognized ECMA-48 and ITU's T.416 specifications do not define a specific color palette for this lookup table. While it is common to use the above formula for the color palette, in particular the algorithm and choice of colors for the 16-231 cube values differs between implementations. The color palette and algorithm used by XTerm is specified below as a sample.[16][38]

The ITU's T.416 Information technology - Open Document Architecture (ODA) and interchange format: Character content architectures[38] uses ":" as separator characters instead:

ESC[38:5:⟨n⟩m Select foreground color      where n is a number from the table below
ESC[48:5:⟨n⟩m Select background color

256-color mode — foreground: ESC[38;5;#m   background: ESC[48;5;#m
Standard colors High-intensity colors
 0   1   2   3   4   5   6   7   8   9  10 11 12 13 14 15
216 colors
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87
88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123
124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159
160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195
196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231
Grayscale colors
232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255

To calculate the RGB values of the colors in the table above, the following Python script can be used:

# print a list of the 256-color red/green/blue values used by xterm.
#
# reference:
# https://github.com/ThomasDickey/ncurses-snapshots/blob/master/test/xterm-16color.dat
# https://github.com/ThomasDickey/xterm-snapshots/blob/master/XTerm-col.ad
# https://github.com/ThomasDickey/xterm-snapshots/blob/master/256colres.pl

print("colors 0-15 correspond to the ANSI and aixterm naming")
for code in range(0, 16):
    if code > 8:
        level = 255
    elif code == 7:
        level = 229
    else:
        level = 205
    r = 127 if code == 8 else level if (code & 1) != 0 else 92 if code == 12 else 0
    g = 127 if code == 8 else level if (code & 2) != 0 else 92 if code == 12 else 0
    b = 127 if code == 8 else 238 if code == 4 else level if (code & 4) != 0 else 0
    print(f"{code:3d}: {r:02X} {g:02X} {b:02X}")

print("colors 16-231 are a 6x6x6 color cube")
for red in range(0, 6):
    for green in range(0, 6):
        for blue in range(0, 6):
            code = 16 + (red * 36) + (green * 6) + blue
            r = red   * 40 + 55 if red   != 0 else 0
            g = green * 40 + 55 if green != 0 else 0
            b = blue  * 40 + 55 if blue  != 0 else 0
            print(f"{code:3d}: {r:02X} {g:02X} {b:02X}")

print("colors 232-255 are a grayscale ramp, intentionally leaving out black and white")
code = 232
for gray in range(0, 24):
    level = gray * 10 + 8
    code = 232 + gray
    print(f"{code:3d}: {level:02X} {level:02X} {level:02X}")

There has also been a similar but incompatible 88-color encoding using the same escape sequence, seen in rxvt and xterm-88color.[39] It uses a 4×4×4 color cube.

24-bit

[edit]

As "true color" graphic cards with 16 to 24 bits of color became common, applications began to support 24-bit colors. Terminal emulators supporting setting 24-bit foreground and background colors with escape sequences include Xterm,[17] KDE's Konsole,[40][41] and iTerm, as well as all libvte based terminals,[42] including GNOME Terminal.[43]

ESC[38;2;⟨r⟩;⟨g⟩;⟨b⟩m Select RGB foreground color
ESC[48;2;⟨r⟩;⟨g⟩;⟨b⟩m Select RGB background color

The syntax is likely based on the ITU's T.416 Open Document Architecture (ODA) and interchange format: Character content architectures,[38] which was adopted as ISO/IEC 8613-6 but ended up as a commercial failure.[citation needed] The ODA version is more elaborate and thus incompatible:

  • The parameters after the '2' (r, g, and b) are optional and can be left empty.
  • Semicolons are replaced by colons, as above.
  • There is a leading "colorspace ID".[17] The definition of the colorspace ID is not included in that specification, so it may be blank to represent the unspecified default. For CMYK color specifications, mintty interprets the colorspace ID parameter as specifying the maximum value which the channel values are given out of (e.g. 100 or 255).[33]
  • In addition to the '2' value after 48 to specify a Red-Green-Blue format (and the '5' above for a 0-255 indexed color), there are alternatives of '0' for implementation-defined and '1' for transparent - neither of which have any further parameters; '3' specifies colors using a Cyan-Magenta-Yellow scheme, and '4' for a Cyan-Magenta-Yellow-Black one, the latter using the position marked as "unused" for the Black component.[38]
ESC[38:2:⟨Color-Space-ID⟩:⟨r⟩:⟨g⟩:⟨b⟩:⟨unused⟩:CS tolerance:⟨Color-Space⟩m Select RGB foreground color
ESC[48:2:⟨Color-Space-ID⟩:⟨r⟩:⟨g⟩:⟨b⟩:⟨unused⟩:⟨CS tolerance⟩:⟨Color-Space⟩m Select RGB background color

where Color-Space indicates the Color-Space associated with the given tolerance: 0 for CIELUV or 1 for CIELAB.

The ITU-RGB variation is supported by xterm, with the colorspace ID and tolerance parameters ignored. The simpler scheme using semicolons is initially found in Konsole.[17]

Unix environment variables relating to color support

[edit]

Rather than using the color support in termcap and terminfo introduced in SVr3.2 (1987),[44] the S-Lang library (version 0.99-32, June 1996) used a separate environment variable $COLORTERM to indicate whether a terminal emulator could use colors at all, and later added values to indicate if it supported 24-bit color.[45][46] This system, although poorly documented, became widespread enough for Fedora and RHEL to consider using it as a simpler and more universal detection mechanism compared to querying the now-updated libraries.[47]

Some terminal emulators (urxvt, Konsole) set $COLORFGBG to report the color scheme of the terminal (mainly light vs. dark background). This behavior originated in S-Lang[46] and is used by vim. Gnome-terminal refuses to add this behavior, as the syntax for the value is not agreed upon, the value cannot be changed upon a runtime change of the palette, and more "proper" xterm OSC 4/10/11 sequences already exist.[48]

Operating System Command sequences

[edit]

Most Operating System Command sequences were defined by Xterm, but many are also supported by other terminal emulators. For historical reasons, Xterm can end the command with BEL (0x07) as well as the standard ST (0x9C or 0x1B 0x5C).[17] For example, Xterm allows the window title to be set by ESC ]0;this is the window title BEL.

A non-xterm extension is the hyperlink, ESC ]8;;link ST from 2017, used by VTE,[49][discuss] iTerm2,[49] and mintty,[50] among others.[51]

The Linux console uses ESC ] P n rr gg bb to change the palette, which, if hard-coded into an application, may hang other terminals.[52] However, appending ST will be ignored by Linux and form a proper, ignorable sequence for other terminals.[citation needed]

Fs Escape sequences

[edit]

If the ESC is followed by a byte in the range 0x60—0x7E, the escape sequence is of type Fs. This type is used for control functions individually registered with the ISO-IR registry.[53] A table of these is listed under ISO/IEC 2022.

Fp Escape sequences

[edit]

If the ESC is followed by a byte in the range 0x30—0x3F, the escape sequence is of type Fp, which is set apart for up to sixteen private-use control functions.[15]: 6.5.3 

Some type Fp (private-use) escape sequences recognised by the VT100
Abbr Name Effect
ESC 7 DECSC DEC Save Cursor Saves the cursor position, encoding shift state and formatting attributes.[54][17]
ESC 8 DECRC DEC Restore Cursor Restores the cursor position, encoding shift state and formatting attributes from the previous DECSC if any, otherwise resets these all to their defaults.[54][17]

nF Escape sequences

[edit]

If the ESC is followed by a byte in the range 0x20—0x2F, the escape sequence is of type nF. Said byte is followed by any number of additional bytes in this range, and then a byte in the range 0x30-0x7E. These escape sequences are further subcategorised by the low two bits of the first byte, e.g. "type 2F" for sequences where the first byte is 0x22; and by whether the final byte is in the range 0x30—0x3F indicating private use (e.g. "type 2Fp") or not (e.g. "type 2Ft").[15]: 13.2.1 

Most of the nFt sequences are for changing the current character set, and are listed in ISO/IEC 2022. Some others:

Some type 0Ft (announcement) ANSI escape sequences[17][15]: 15.2 
Abbr Name Effect
ESC SP F
  • ACS6
  • S7C1T
  • Announce Code Structure 6
  • Send 7-bit C1 Control Character to the Host
Makes the function keys send ESC + letter instead of 8-bit C1 codes.
ESC SP G
  • ACS7
  • S8C1T
  • Announce Code Structure 7
  • Send 8-bit C1 Control Character to the Host
Makes the function keys send 8-bit C1 codes.

If the first byte is '#' the public sequences are reserved for additional ISO-IR registered individual control functions.[15]: 6.5.2  No such sequences are presently registered.[53] Type 3Fp sequences (which includes ones starting with '#') are available for private-use control functions.[15]: 6.5.3 

Some type 3Fp (private-use) escape sequences recognised by the VT100
Abbr Name Effect
ESC # 3 DECDHL DEC Double-Height Letters, Top Half Makes the current line use characters twice as tall. This code is for the top half.[55]
ESC # 4 DECDHL DEC Double-Height Letters, Bottom Half Makes the current line use characters twice as tall. This code is for the bottom half.[55]
ESC # 5 DECSWL DEC Single-Width Line Makes the current line use single-width characters, per the default behaviour.[56][17]
ESC # 6 DECDWL DEC Double-Width Line Makes the current line use double-width characters, discarding any characters in the second half of the line.[57][17]

Examples

[edit]

CSI 2 J — This clears the screen and, on some devices, locates the cursor to the y,x position 1,1 (upper left corner).

CSI 32 m — This makes text green. The green may be a dark, dull green, so you may wish to enable Bold with the sequence CSI 1 m which would make it bright green, or combined as CSI 32 ; 1 m. Some implementations use the Bold state to make the character Bright.

CSI 0 ; 6 8 ; "DIR" ; 13 p — This reassigns the key F10 to send to the keyboard buffer the string "DIR" and ENTER, which in the DOS command line would display the contents of the current directory. (MS-DOS ANSI.SYS only) This was sometimes used for ANSI bombs. This is a private-use code (as indicated by the letter p), using a non-standard extension to include a string-valued parameter. Following the letter of the standard would consider the sequence to end at the letter D.

CSI s — This saves the cursor position. Using the sequence CSI u will restore it to the position. Say the current cursor position is 7(y) and 10(x). The sequence CSI s will save those two numbers. Now you can move to a different cursor position, such as 20(y) and 3(x), using the sequence CSI 20 ; 3 H or CSI 20 ; 3 f. Now if you use the sequence CSI u the cursor position will return to 7(y) and 10(x). Some terminals require the DEC sequences ESC 7 / ESC 8 instead which is more widely supported.

In shell scripting

[edit]

ANSI escape codes are often used in UNIX and UNIX-like terminals to provide syntax highlighting. For example, on compatible terminals, the following list command color-codes file and directory names by type.

ls --color

Users can employ escape codes in their scripts by including them as part of standard output or standard error. For example, the following GNU sed command embellishes the output of the make command by displaying lines containing words starting with "WARN" in reverse video and words starting with "ERR" in bright yellow on a dark red background (letter case is ignored). The representations of the codes are highlighted.[58]

make 2>&1 | sed -e 's/.*\bWARN.*/\x1b[7m&\x1b[0m/i' -e 's/.*\bERR.*/\x1b[93;41m&\x1b[0m/i'

The following Bash function flashes the terminal (by alternately sending reverse and normal video mode codes) until the user presses a key.[59] It can be used to alert a programmer when a lengthy command terminates, such as with make ; flasher.[60]

flasher () { while true; do printf '\e[?5h'; sleep 0.1; printf '\e[?5l'; read -s -n1 -t1 && break; done; }

The following command will reset the console, similar to the command reset on modern Linux systems; however it should work even on older Linux systems and on other (non-Linux) UNIX variants.

printf '\033c'

In C

[edit]

This following program creates a table of numbers from 0 to 109, each of which is displayed in the format specified by the Select Graphic Rendition escape sequence using that number as the graphic rendition code.

Output of example program on Gnome Terminal
#include <stdio.h>

int main(void)
{
    int row, col, n;

    for (row = 0; row < 11; row++) {
        for (col = 0; col < 10; col++) {
            n = 10 * row + col;
            if (n > 109) break;
            printf("\033[%dm %3d\033[m", n, n);
        }
        printf("\n");
    }
    return 0;
}

Terminal input sequences

[edit]

Pressing special keys on the keyboard, as well as outputting many xterm CSI, DCS, or OSC sequences, often produces a CSI, DCS, or OSC sequence, sent from the terminal to the computer as though the user typed it.

When typing input on a terminal keypresses outside the normal main alphanumeric keyboard area can be sent to the host as ANSI sequences. For keys that have an equivalent output function, such as the cursor keys, these often mirror the output sequences. However, for most keypresses there isn't an equivalent output sequence to use.

There are several encoding schemes, and unfortunately most terminals mix sequences from different schemes, so host software has to be able to deal with input sequences using any scheme. To complicate the matter, the VT terminals themselves have two schemes of input, normal mode and application mode that can be switched by the application.

(draft section)

<char>                                         -> char
<esc>                                          -> esc
<esc> <esc>                                    -> Alt-esc
<esc> <char>                                   -> Alt-keypress or keycode sequence
<esc> '['                                      -> Alt-[
<esc> '[' (<modifier>) <char>                  -> keycode sequence, <modifier> is a decimal
                                                  number and defaults to 1 (xterm)
<esc> '[' (<keycode>) (';'<modifier>) '~'      -> keycode sequence, <keycode> and <modifier>
                                                  are decimal numbers and default to 1 (vt)

If the terminating character is '~', the first number must be present and is a keycode number, the second number is an optional modifier value. If the terminating character is a letter, the letter is the keycode value, and the optional number is the modifier value.

The modifier value defaults to 1, and after subtracting 1 is a bitmap of modifier keys being pressed: Meta+Ctrl+Alt+⇧ Shift. So, for example, <esc>[4;2~ is ⇧ Shift+End, <esc>[20~ is function key F9, <esc>[5C is Ctrl+.

In other words, the modifier is the sum of the following numbers:

Key pressed Number Comment
1 always added, the rest are optional
Shift 1
(Left) Alt 2
Control 4
Meta 8
vt sequences:
<esc>[1~    - Home        <esc>[16~   -             <esc>[31~   - F17
<esc>[2~    - Insert      <esc>[17~   - F6          <esc>[32~   - F18
<esc>[3~    - Delete      <esc>[18~   - F7          <esc>[33~   - F19
<esc>[4~    - End         <esc>[19~   - F8          <esc>[34~   - F20
<esc>[5~    - PgUp        <esc>[20~   - F9          <esc>[35~   - 
<esc>[6~    - PgDn        <esc>[21~   - F10         
<esc>[7~    - Home        <esc>[22~   -             
<esc>[8~    - End         <esc>[23~   - F11         
<esc>[9~    -             <esc>[24~   - F12         
<esc>[10~   - F0          <esc>[25~   - F13         
<esc>[11~   - F1          <esc>[26~   - F14         
<esc>[12~   - F2          <esc>[27~   -             
<esc>[13~   - F3          <esc>[28~   - F15         
<esc>[14~   - F4          <esc>[29~   - F16         
<esc>[15~   - F5          <esc>[30~   -

xterm sequences:
<esc>[A     - Up          <esc>[K     -             <esc>[U     -
<esc>[B     - Down        <esc>[L     -             <esc>[V     -
<esc>[C     - Right       <esc>[M     -             <esc>[W     -
<esc>[D     - Left        <esc>[N     -             <esc>[X     -
<esc>[E     -             <esc>[O     -             <esc>[Y     -
<esc>[F     - End         <esc>[1P    - F1          <esc>[Z     -
<esc>[G     - Keypad 5    <esc>[1Q    - F2       
<esc>[H     - Home        <esc>[1R    - F3       
<esc>[I     -             <esc>[1S    - F4       
<esc>[J     -             <esc>[T     - 

<esc>[A to <esc>[D are the same as the ANSI output sequences. The <modifier> is normally omitted if no modifier keys are pressed, but most implementations always emit the <modifier> for F1F4. (draft section)

Xterm has a comprehensive documentation page on the various function-key and mouse input sequence schemes from DEC's VT terminals and various other terminals it emulates.[17] Thomas Dickey has added a lot of support to it over time;[61] he also maintains a list of default keys used by other terminal emulators for comparison.[62]

  • On the Linux console, certain function keys generate sequences of the form CSI [ char. The CSI sequence should terminate on the [.
  • Old versions of Terminator generate SS3 1; modifiers char when F1F4 are pressed with modifiers. The faulty behavior was copied from GNOME Terminal.[citation needed]
  • xterm replies CSI row ; column R if asked for cursor position and CSI 1 ; modifiers R if the F3 key is pressed with modifiers, which collide in the case of row == 1. This can be avoided by using the ? private modifier as CSI ? 6 n, which will be reflected in the response as CSI ? row ; column R.
  • many terminals prepend ESC to any character that is typed with the alt key down. This creates ambiguity for uppercase letters and symbols @[\]^_, which would form C1 codes.[clarification needed]
  • Konsole generates SS3 modifiers char when F1F4 are pressed with modifiers.[clarification needed]
  • iTerm2 supports reporting additional keys via an enhanced CSI u mode.[63]

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia
from Grokipedia
ANSI escape codes, also known as ANSI escape sequences, are standardized control functions embedded in text streams to direct the operation of video display terminals and compatible character-imaging devices, enabling precise control over text presentation, including cursor movement, screen formatting, color selection, and stylistic attributes such as bold or underline. The codes originated in the 1970s as part of efforts to extend the basic ASCII character set for interactive computing environments. The foundational American standard, ANSI X3.64 (approved in 1979 and published as FIPS PUB 86 in 1979), defined additional encoded controls for two-dimensional input-output devices like terminals and printers, using escape sequences to facilitate data interchange, editing, and formatting. This aligned with the earlier ECMA-48 standard, first edition published by in 1976, which specified control functions for 7-bit and 8-bit coded character sets to support consistent device behavior across systems. ECMA-48 was subsequently adopted internationally as ISO/IEC 6429, with the second edition in 1988 and third in 1992, incorporating enhancements like handling while maintaining compatibility with prior versions. In practice, ANSI escape codes typically begin with the (ESC, ASCII 27 or \x1B), followed by a like the Control Sequence Introducer (CSI, ESC [ or single-byte 0x9B in 8-bit environments), parameters (numeric or selective values), intermediate characters if needed, and a final byte to invoke the function. They are integral to consoles, supporting operations such as clearing the screen (CSI 2 J), moving the cursor (CSI Pn ; Pn H for absolute positioning), and setting graphic renditions like foreground color (CSI 31 m for red text). Modern terminal emulators, including those in distributions, implement a large subset of these sequences alongside extensions for advanced features, ensuring while enhancing user interfaces in command-line tools and applications.

History and Development

Origins in Terminals

In the , the rise of video display terminals created a demand for control mechanisms beyond the basic ASCII C0 control characters, enabling dynamic cursor positioning, screen manipulation, and text formatting on character-based displays. These terminals, used for interacting with mainframe computers, required efficient ways to manage limited screen real estate without relying solely on hardware switches or vendor-proprietary commands. Early implementations appeared in terminals like the Lear-Siegler , introduced in 1976 as an affordable ASCII-based video display unit with a 12-inch screen supporting 24 lines of 80 characters. The employed escape sequences for key functions, such as cursor addressing via the (ASCII 27) followed by '=' and row/column codes (e.g., ESC = followed by space for row 1 and space for column 1, where space represents position 1 and subsequent characters increment accordingly up to '/' for row 16 and '_' for column 80), which allowed host computers to direct on-screen operations programmatically. This approach addressed the limitations of simpler teleprinter-style devices by providing flexible, software-driven control over the display. Heathkit terminals, such as the H19 model released in 1979, further advanced this by incorporating escape sequences for cursor movement, line insertion/deletion, and mode switching in both proprietary Heath and emerging ANSI-compatible modes. The H19's design, aimed at hobbyists and small systems, used sequences like ESC H for cursor home and ESC A for upward movement, building on ASCII foundations to support more interactive applications. Digital Equipment Corporation's VT52, introduced in 1975, played a key role by popularizing escape sequences for cursor control and editing functions, such as ESC A for cursor up, influencing subsequent terminal designs. The Digital Equipment Corporation's VT100, launched in August 1978, marked a pivotal step by standardizing escape sequences for cursor control, screen clearing, and basic attributes like reverse video, making it compatible with prior DEC models while influencing broader industry adoption. Its sequences, such as ESC [ H for cursor home, facilitated reliable data interchange in multi-vendor environments. This progression from ASCII's 1963 C0 controls—limited to functions like and line feed—to escape-initiated sequences enabled richer formatting and control, evolving toward structured commands like those in later CSI formats. The ANSI X3.64-1979 standard formalized these developments by defining additional C1 controls and escape sequences for two-dimensional imaging devices, including cursor positioning (e.g., for cursor to specific row/column) and text attributes (e.g., SGR for selective graphic rendition), to promote among terminals. Adopted by the U.S. as FIPS PUB 86 in 1981, it built directly on terminal innovations to standardize control for cursor movement and formatting.

Standardization Efforts

The formal standardization of escape codes for video terminals built on industry efforts in the late 1970s, aligning with international developments in control sequences for information interchange. The (ANSI) published X3.64-1979, titled "Additional Controls for Use with American National Standard Code for Information Interchange," which defined escape sequences and control functions specifically for video display terminals and peripherals, including cursor positioning and basic graphic renditions. This standard built upon the ASCII framework (ANSI X3.4-1977) by introducing structured escape sequences to enable device-independent text formatting. The standard was reaffirmed in 1990 (ANSI X3.64-1979/R1990) to align with emerging international efforts, enhancing compatibility for video terminal operations. Concurrently, released the first edition of ECMA-48 in 1976, establishing control functions for coded character sets, including escape sequences that paralleled and influenced ANSI developments. The fourth edition of ECMA-48, published in 1986, was adopted via fast-track procedure as the second edition of ISO/IEC 6429, providing equivalent international mappings for 7-bit and 8-bit coded representations of control functions and ensuring global . The fifth edition in June 1991 added support for bi-directional text processing and was subsequently adopted as the third edition of ISO/IEC 6429. ANSI X3.64 was ultimately withdrawn in 1997 in favor of these ISO/IEC standards. Subsequent extensions appeared in ISO/IEC 8613 (also known as T.410 series), published in the late with amendments through the , which focused on open document architecture for interchange and incorporated escape-based controls for raster and geometric , including indexed and direct color specifications. These standards influenced the Consortium's mappings of , integrating compatibility into the Standard (version 1.0, 1991 onward) for multilingual text processing. In the , updates to related standards and implementations extended support for 256-color palettes and true color modes, building on the foundational CSI structures for enhanced graphic renditions.

Fundamental Components

C0 Control Codes

The C0 control codes form the foundational set of non-printable characters in the 7-bit ASCII standard (ANSI X3.4-1968) and the international ISO/IEC 646 standard, occupying code positions 0 through 31 ( 0x00 to 0x1F) and position 127 (0x7F). These codes are designed for device control functions in data interchange, such as formatting output on terminals or printers, without representing visible graphics. Unlike graphic characters, C0 codes perform immediate actions upon receipt, enabling essential operations like cursor movement and signaling without multi-byte prefixes. Key C0 codes include those for alerting, positioning, erasing, and sequence initiation, each with defined binary and representations. The BEL (bell) code, at 7 (binary 0000111, 0x07), generates an audible or visible signal to alert the user or operator. The ESC (escape) code, at 27 (binary 0011011, 0x1B), serves as an introducer for code extension techniques, allowing terminals to interpret subsequent bytes as control commands rather than printable characters. The DEL (delete) code, at 127 (binary 1111111, 0x7F), is a format effector that substitutes an ignorable character to obliterate an erroneous one in data streams or media like paper tape, and is often used for padding in asynchronous transmission. C0 codes also support basic text positioning without escape sequences, facilitating simple terminal navigation. The LF (line feed) code, at 10 (binary 0001010, 0x0A), advances the active position to the next line, typically moving the cursor down one row while preserving the horizontal position. Similarly, the CR () code, at 13 (binary 0001101, 0x0D), returns the active position to the first column of the current line, enabling line beginnings and text wrapping. These single-byte controls provide efficient, prefix-free mechanisms for core terminal behaviors, with ESC acting as a bridge to more complex sequences.
Code NameDecimalBinaryHexadecimalRole
BEL700001110x07Audible signal for alerts.
LF1000010100x0AAdvance to next line.
CR1300011010x0DReturn to line start.
ESC2700110110x1BInitiate control sequences.
12711111110x7FObliterate erroneous data or pad transmission.

Escape Sequences Overview

ANSI escape sequences provide a mechanism to extend the functionality of basic C0 control codes, enabling terminals to perform advanced operations such as cursor positioning, screen erasure, and character set selection. These sequences are defined in the ECMA-48 standard, which specifies their coded representations for use in 7-bit and 8-bit environments. The general syntax of an consists of the ESC character (bit combination 01/11, equivalent to ASCII 27 or 0x1B), followed by zero or more intermediate bytes (bit combinations 02/00 through 02/15), and terminated by a final byte (bit combinations 04/00 through 07/14, excluding 02/08 through 02/13 and delete codes). This structure, denoted as ESC I...I F, allows for the introduction of control functions that alter the interpretation of subsequent data, such as shifting character sets or invoking device-specific behaviors. In contrast to single-byte C0 codes like (CR) or line feed (LF), s support parameterized instructions, facilitating precise control over terminal attributes. Escape sequences are categorized into several types based on their structure and final bytes, each serving distinct roles in terminal control. Single-shift sequences (denoted with final byte Fe in the range 04/00–05/15) temporarily invoke an alternative character set for the next character only; for example, ESC N (Fe = 04/14) performs a single shift to the G2 set (SS2). Independent control functions use final bytes Fs in the range 06/00–07/14, such as ESC ( B to designate the G0 set as ASCII (LS0). Privacy escape sequences (Fp) incorporate private-use parameters or intermediates for vendor-specific extensions, while nF sequences allow multiple final bytes for compound functions. A prominent type is the Control Sequence Introducer (CSI), formed by ESC followed by the intermediate byte [ (05/11), resulting in the 8-bit equivalent 09/11; this is followed by optional parameters, additional intermediates, and a final byte, as in CSI c (final byte 'c' or 06/03) for full reset of the terminal. Common intermediate bytes include [ for CSI to introduce parameterized commands like cursor movement (e.g., CSI n A to move up n lines) or screen clearing (e.g., CSI 2 J to clear the entire screen), thereby expanding C0's limited scope to support interactive text-based interfaces. Other intermediates, such as ] (05/14) for Operating System Command (OSC) strings, enable further extensions but adhere to the same foundational format.

Control Sequence Introducer (CSI) Commands

CSI Structure and Syntax

The Control Sequence Introducer (CSI) serves as the initiator for a broad class of parameterized control functions in the ANSI escape code system, enabling precise terminal operations such as cursor movement and mode setting. In 7-bit environments, CSI is encoded as the escape sequence ESC followed by the left square bracket '[' (bit combination 05/11), while in 8-bit environments, it is a single byte with the value 0x9B (09/11). This representation aligns with the C1 control set defined in ECMA-48, distinguishing CSI from simpler s. The syntax of a CSI command follows the format CSI P...P I...I F, where the sequence begins with the CSI introducer, followed by zero or more strings (P), optional intermediate characters (I), and a mandatory final character (F) that specifies the control function. Parameters are integers formed from digit characters (0-9), with multiple parameters separated by semicolons (;); each string may be empty, in which case it assumes a function-specific default value, often 0 or 1. Numeric ranges for parameters are not strictly bounded in the standard but are typically positive integers limited by device capabilities, such as screen dimensions for positioning commands; leading zeros in parameters are ignored except to represent zero itself. Intermediate characters, drawn from the range of printable ASCII (02/00 to 02/15), are optional and usually limited to one; they include private-use prefixes like '?' for DEC-specific extensions or '>' for user-defined modes. The final character (04/00 to 07/14) terminates the sequence and identifies the action, with values in 07/00 to 07/14 reserved for private use. A representative example is the Cursor Position (CUP) command, which repositions the cursor to specified row and column coordinates: ESC [Pn1;Pn2 H, where Pn1 defaults to 1 (top row) and Pn2 to 1 (left column) if omitted, and both parameters exceed screen bounds only if the terminal implementation allows wrapping or clipping. Private-use prefixes modify this structure for vendor-specific behaviors; for instance, DEC private modes employ the intermediate '?' followed by parameters and finals like 'h' (set) or 'l' (reset), as in ESC [?1 h to enable the application cursor key mode. Parsers handle CSI sequences by accumulating digits into parameters until a semicolon, intermediate, or final is encountered, with invalid bit combinations (e.g., non-digit in parameters or unallocated finals) treated as implementation-dependent—often ignored or causing the sequence to abort without effect to maintain forward compatibility. In DEC private modes, unrecognized parameters may default to no operation, ensuring robustness in mixed environments. This error-tolerant parsing prevents cascading failures from malformed input.

Select Graphic Rendition (SGR) Parameters

The Select Graphic Rendition (SGR) control function enables terminals to apply visual attributes to subsequent characters, such as intensity, font styles, colors, and other effects, without altering the character encoding itself. Defined in the ECMA-48 standard (also known as ISO/IEC 6429), SGR operates as a selective parameter sequence that modifies the rendition cumulatively or by replacement, depending on the terminal's graphic rendition combination mode (GRCM). Attributes take effect at the active cursor position and persist until overridden by another SGR sequence or a reset. If no parameters are specified, the default is normal rendition (equivalent to parameter 0). The SGR sequence follows the Control Sequence Introducer (CSI) format: ESC [ Ps ; Ps ; ... m, where ESC is the escape character (0x1B), [ introduces the sequence, Ps represents one or more numeric parameters separated by semicolons, and m (0x6D) is the final character. Multiple parameters can be combined in a single sequence to apply several attributes simultaneously, such as ESC [1;31m for bold red foreground text. The effects are implementation-dependent, with support varying by terminal; for instance, some attributes like faint intensity may render as grayscale. Standard ECMA-48 parameters cover basic text attributes and 8-color palettes, as detailed below. These are widely supported in ANSI-compatible terminals.
ParameterEffect
0Normal rendition (resets all attributes)
1Bold or increased intensity
2Faint or decreased intensity
3Italicized text
4Single underline
5Slow blink (less than 150 blinks per minute)
6Rapid blink (150 or more blinks per minute)
7Negative image (reverse foreground and background)
8Concealed (invisible) text
9Crossed-out (strikethrough)
10Primary (default) font
11–19Alternative fonts (first to ninth alternative)
20Fraktur (Gothic style, rarely supported)
21Double underline
22Normal intensity (neither bold nor faint)
23Not italicized (or not Fraktur)
24Not underlined
25Steady (no blink)
27Positive image (no reverse)
28Visible (no conceal)
29Not crossed-out
30Foreground: black
31Foreground: red
32Foreground: green
33Foreground: yellow
34Foreground: blue
35Foreground: magenta
36Foreground: cyan
37Foreground: white
39Default foreground color
40Background: black
41Background: red
42Background: green
43Background: yellow
44Background: blue
45Background: magenta
46Background: cyan
47Background: white
49Default background color
Later extensions, originating from terminal emulators like , expand SGR for advanced color support beyond the ECMA-48 8-color limit. These are not part of the core standard but are commonly implemented in modern terminals for 256 indexed colors and 24-bit true color (RGB). For 256-color mode, the sequence uses ESC [38;5;<n>m for foreground or ESC [48;5;<n>m for background, where <n> is an index from 0 (black) to 255 (bright white); indices 0–15 match the basic colors, 16–231 form a 6x6x6 RGB cube, and 232–255 provide grayscale shades. This extension, introduced in xterm version 195 (2004), draws from ISO-8613 but uses semicolons for backward compatibility. True color support employs ESC [38;2;<r>;<g>;<b>m for foreground or ESC [48;2;<r>;<g>;<b>m for background, with <r>, <g>, and <b> as 8-bit (0–255) values for red, green, and blue components, respectively. Added in xterm version 282 (2012), this allows arbitrary colors but requires direct-color-capable hardware and software; unsupported terminals may approximate with the nearest palette match or ignore the sequence. Compatibility is high in systems and modern Windows terminals but varies in legacy environments.

Color Handling

Basic Color Codes

The basic color codes in ANSI escape sequences are part of the Select Graphic Rendition (SGR) parameters, which allow terminals to set foreground and background colors using a limited palette derived from early 3-bit color models. These codes, standardized in the ECMA-48 specification, map to eight primary colors: black, red, green, yellow, blue, magenta, cyan, and white. Foreground colors are specified with parameters 30–37, while background colors use 40–47, providing a total of 16 possible combinations when both are set. The color mappings follow a consistent indexing scheme where the value corresponds to the (0 for through 7 for ). For example:
ParameterForeground ColorBackground Color
30 / 40
31 / 41RedRed
32 / 42
33 / 43YellowYellow
34 / 44
35 / 45
36 / 46
37 / 47White
These mappings are defined in the second edition of ECMA-48 (1979), which allocated SGR parameters 30–37 and 40–47 for 3-bit foreground and background colors, respectively. Although standardized in 1979, practical hardware support began in the early 1980s with terminals such as the TeleVideo 950. The syntax for applying these codes is \e[Ps m, where \e represents the escape character (ASCII 27 or octal 033), [ introduces the control sequence, Ps is the numeric parameter (e.g., 31 for red foreground), and m selects the graphic rendition. For foreground, Ps takes the form 3n where n ranges from 0 to 7 (e.g., \e[31m for red text); for background, it is 4n (e.g., \e[41m for red background). Multiple parameters can be chained with semicolons, such as \e[31;42m for red text on a green background, and the default rendition is reset with \e[0m. To extend the palette to a 4-bit model supporting 16 colors, many terminals implement bright variants of the basic colors using parameters 90–97 for bright foreground and 100–107 for bright background. These provide intensified versions of the same hues, often rendering as bolder or lighter shades (e.g., 90 for bright black, typically gray; 91 for bright red). This extension originated in implementations like AIXterm and xterm, becoming a de facto standard despite not being part of the core ECMA-48 specification. The same indexing applies: 9n for bright foreground and 10n for bright background, with n from 0 to 7 (e.g., \e[91m for bright red text). Historically, these basic color codes were designed for early ANSI-compatible terminals in the late and , such as the DEC VT340 series, which supported only the 8-color 3-bit set per type due to hardware limitations in displays and memory. The addition of bright variants in the 4-bit extension addressed demands for higher contrast in text-based interfaces, enabling a total of 16 distinct colors while maintaining with the original standard.

Extended and True Color Support

Extended color support in ANSI escape sequences builds upon the basic 16-color palette by introducing higher-fidelity options for terminals capable of rendering more nuanced hues. The 256-color mode, often referred to as , utilizes the Select Graphic Rendition (SGR) parameters 38;5;<n> for foreground colors and 48;5;<n> for background colors, where <n> is an from 0 to 255 indexing into a predefined palette. This palette is divided into three segments: indices 0–15 correspond to the standard ANSI colors (dark variants 0–7 and bright variants 8–15); indices 16–231 form a 6×6×6 RGB color , providing 216 colors by evenly spacing red, green, and blue components at levels 0/95/135/175/215/255; and indices 232–255 comprise a 24-step ramp from black (RGB 0,0,0) to white (RGB 255,255,255). This structure allows for a broader range of colors while remaining compatible with indexed rendering in terminals like . Further extending capabilities, 24-bit true color support enables direct specification of arbitrary RGB values without relying on a fixed palette. This is achieved through SGR parameters 38;2;<r>;<g>;<b> for foreground and 48;2;<r>;<g>;<b> for background, where <r>, <g>, and <b> are integers from 0 to 255 representing the red, green, and blue components, respectively; the sequence is terminated with m (e.g., \e[38;2;255;0;0m for pure red text). True color, supporting over 16 million combinations, originated as an extension in terminals like xterm (when compiled with direct-color visuals) and is defined in ISO-8613-6 for direct color modes, allowing precise color reproduction in applications such as image viewers or data visualizations. If true color is unavailable, terminals typically approximate by mapping to the nearest palette entry. To detect support for these extended modes in environments, applications consult the TERM and associated databases managed by libraries like ; for instance, TERM=xterm-256color signals 256-color capability via the Co#256 entry, while the presence of an RGB boolean indicates true color support. Additionally, some terminals set the COLORTERM to truecolor (or variants like 24bit) to explicitly advertise 24-bit color availability, a convention adopted by modern emulators to aid programmatic detection. In the 2020s, adoption of these features has become widespread among terminal emulators, with iTerm2 and Alacritty providing full 256-color and true color support out of the box, including GPU-accelerated rendering for smooth performance in high-resolution displays. These emulators set appropriate environment variables and terminfo entries to ensure seamless integration with tools like ncurses-based applications.

Specialized Escape Sequences

Operating System Command (OSC) Sequences

Operating System Command (OSC) sequences provide a mechanism for terminals to invoke operating system-level functions and set or query terminal status information at the application level, such as manipulating properties, colors, and data. These extend beyond core ANSI control functions and are initiated by the followed by a right square bracket (ESC ], or single-byte 0x9D in 8-bit environments), making them distinct from Control Sequence Introducer (CSI) commands that start with ESC [. The OSC format is standardized in ECMA-48 (adopted as ISO/IEC 6429), though many specific commands (Ps values) originated as extensions in early terminal emulators like the VT100 and have been widely adopted in modern implementations, particularly xterm and its derivatives. The general syntax for an OSC sequence is ESC ] Ps ; Pt BEL or ESC ] Ps ; Pt ST, where Ps is a numeric parameter indicating the command type, Pt is an optional text parameter providing additional data (such as strings or color specifications), and the sequence terminates with either BEL (, ASCII 7) or ST (string terminator, ESC ). Whitespace between elements is typically ignored, allowing flexibility in implementation. For instance, to set the window title to "My Application", the sequence ESC ] 2 ; My Application BEL (or \e]2;My Application\a where \e is ESC and \a is BEL) is emitted, causing compatible terminals to update the title bar accordingly. To report the current status, Pt can be "?" such as ESC ] 2 ; ? ST, prompting the terminal to respond with the existing title via a CSI sequence. Common uses include window and icon management:
Ps ValueDescriptionExample SequenceEffect
0Set both icon name and window titleESC ] 0 ; Icon ; Title BELUpdates icon label and title bar to "Title", with "Icon" for minimized view
1Set icon name onlyESC ] 1 ; Icon BELChanges the icon label (e.g., for taskbar or window switcher)
2Set window title onlyESC ] 2 ; Title BELModifies the title bar text
Querying follows the same Ps values with Pt = "?" to retrieve current values, enabling applications to synchronize status. Extended uses include hypertext features in modern terminals, where sequences like ESC ] 8 ; ; https://example.com ST associate hyperlinks with subsequent text until terminated by ESC ] 8 ; ; ST, allowing clickable URLs in output. OSC sequences differ from CSI commands in their scope and termination: while CSI handles low-level terminal attributes like cursor position (ending in letters like 'H' for cursor home), OSC targets application-facing status like UI elements, often interfacing with the host OS. This makes them suitable for shell prompts or programs to dynamically update visible metadata without altering display content. Key OSC commands also focus on color palette manipulation, which is essential for customizing terminal appearance without relying solely on SGR parameters. To change a specific color in the palette (e.g., one of the 16 ANSI colors indexed 0-15), the sequence OSC 4 ; c ; spec BEL is used, where c is the and spec is either a color name (like "") or an RGB value in the format "rgb:rr/gg/bb" (with rr, gg, bb as two-digit values). An older, compatible form for the 16-color palette is OSC P nrrggbb BEL, where n is the index (0-15) and rrggbb are concatenated RGB components without slashes. For example, setting color 1 () to pure red uses \e]P1ff0000\a. These commands allow dynamic palette adjustments, supporting up to 256 colors in extended modes if the terminal is compiled accordingly. To reset a color to its default, OSC 104 ; c BEL restores the value for index c, ensuring reversibility in applications. Additional color-related commands target specific elements: OSC 10 ; spec BEL sets the default foreground color, OSC 11 ; spec BEL sets the background color, and OSC 12 ; spec BEL sets the text cursor foreground color, each using the same RGB specification format. These are particularly useful for global theme changes in terminal sessions. For clipboard access, a critical OS interaction, OSC 52 ; Pc ; Pd BEL enables reading from or writing to selection buffers. Here, Pc specifies the buffer type (e.g., "c" for clipboard, "p" for primary selection, "s" for secondary, or numbers 0-7 for cut buffers), and Pd is either base64-encoded data to write or "?" to query the current contents, which the terminal responds to via another OSC sequence. This facilitates copy-paste operations across remote sessions, such as in SSH or tmux environments. OSC sequences are inherently vendor-specific for many Ps values, leading to variations across terminals; for example, while supports querying colors with OSC 4 ; c ; ? BEL to receive an OSC 4 response with the current value, not all emulators do. Their commonality stems from adoption in xterm derivatives like , urxvt, and even , making them a for OS interactions in environments. However, compatibility requires testing, as some commands (e.g., clipboard operations) may fail in non-xterm-compatible terminals without proper selection handling. Security considerations arise with OSC sequences due to their potential for abuse in prompt injection attacks. Malicious input can embed control characters within Pt strings, such as newlines to inject shell commands (e.g., ESC ] 2 ; Fake Title\nmalicious_command BEL), leading to in vulnerable terminals like older versions of (CVE-2015-8971). Similarly, spoofed titles have enabled in environments like by mimicking trusted prompts (CVE-2021-25743). Modern shells and terminals mitigate this by sanitizing inputs, but applications should escape user-provided strings in OSC parameters to prevent exploitation.

Platform Compatibility

Unix-like Systems

In Unix-like systems such as and macOS, terminal emulators have provided native support for ANSI escape codes since the late and early , enabling control over text attributes, cursor positioning, and colors in text-based interfaces. xterm, developed in 1984 as an X11 terminal emulator, incorporates ANSI escape sequences through its emulation of the standard, which introduced these codes in 1978 for standardized terminal control. [GNOME Terminal](/page/GNOME Terminal), released with 1.0 in 1999, and , introduced as part of in 1998, have included full ANSI support from their initial versions, allowing seamless integration with command-line applications. As of 2025, [GNOME Terminal](/page/GNOME Terminal) is being replaced by Ptyxis in recent GNOME-based distributions such as 25.10, which continues to support ANSI escape codes. The TERM is essential for specifying the terminal type, which dictates the available capabilities including ANSI escape code interpretation; for instance, TERM=xterm-256color activates support for extended 256-color palettes via sequences like \E[38;5;<n>m for foreground colors. This variable interfaces with the terminfo database, a compiled repository of terminal descriptions that maps capabilities—such as color setting (setaf=\E[3%p1%dm) and cursor addressing (cup=\E[%i%p1%d;%p2%dH)—to portable queries, ensuring applications adapt to the emulator's features without hardcoding sequences. Modern Linux distributions since around 2010 have widely adopted full 24-bit (true) color support in terminals, utilizing extended ANSI sequences like \E[38;2;<r>;<g>;<b>m for direct RGB specification, building on the basic 8- or 16-color foundations. Libraries such as ncurses abstract these capabilities by leveraging terminfo to generate vendor-neutral output, shielding developers from direct ANSI code management while supporting features up to true color in compatible environments. A frequent challenge in Unix-like systems involves legacy TERM settings like vt100, which emulate the original VT100 hardware lacking native color support—relying instead on basic attributes like bold (\E[1m)—resulting in uncolored output even when modern emulators could render more. Programs can detect and mitigate this using tput commands, such as tput colors to query the number of supported colors (e.g., outputting 8 for basic ANSI or 256 for extended), allowing conditional fallback to monochrome modes.

Windows and DOS Environments

In MS-DOS environments, native support for ANSI escape codes was absent in early versions, requiring the loading of the ANSI.SYS device driver to enable basic terminal emulation features such as cursor control and text attributes. Introduced with MS-DOS 2.0 in March 1983, ANSI.SYS interpreted a subset of ANSI sequences, including those for colors and screen clearing, but its functionality was limited compared to Unix terminals and depended on manual configuration via AUTOEXEC.BAT. This driver remained compatible through subsequent MS-DOS releases but was discontinued in Windows NT-based systems starting from Windows 2000, leaving a gap in ANSI handling for command-line interfaces. The Windows Console Host (conhost.exe), used in versions prior to , provided no native interpretation of ANSI escape sequences, relying instead on proprietary commands for basic formatting like the COLOR utility for text attributes. Full ANSI/ compatibility was introduced in the Anniversary Update (version 1607) on August 2, 2016, allowing sequences for cursor movement, colors, and other controls when enabled via the ENABLE_VIRTUAL_TERMINAL_PROCESSING console mode flag. This update extended to 24-bit true color support through RGB escape codes, marking a significant alignment with cross-platform standards. To address legacy limitations in pre-Windows 10 environments or enhance compatibility, third-party libraries such as Colorama for Python wrap ANSI sequences to emulate them on Windows by translating to console API calls. Similarly, the Windows Terminal application, released in 2019 as a modern alternative to conhost.exe, natively supports extended ANSI features including 24-bit colors and is recommended for applications requiring rich terminal rendering. In the 2020s, PowerShell 7, first released in 2018 and updated through versions like 7.4 in 2023 and 7.5 in 2025, incorporated enhancements for consistent ANSI rendering across Windows, Linux, and macOS, including PSStyle class methods for mapping colors to escape sequences and improved terminal detection. These updates facilitate cross-platform scripting with ANSI-dependent tools, reducing discrepancies in output formatting.

Practical Usage

Shell Scripting Examples

In shell scripting, ANSI escape codes are commonly employed to enhance output readability, such as by applying colors to text via the echo command with the -e option enabled for escape sequence interpretation. For instance, the following Bash snippet prints red text followed by a reset to default formatting:

bash

echo -e "\e[31mRed text\e[0m"

echo -e "\e[31mRed text\e[0m"

This utilizes the Select Graphic Rendition (SGR) sequence \e[31m for red foreground and \e[0m to reset attributes. To improve portability across different terminals, scripts often use the tput utility, which queries the terminfo database based on the $TERM environment variable to generate appropriate escape sequences without hardcoding them. A portable function for setting foreground colors might define variables like this:

bash

if [ -t 1 ]; then RED=$(tput setaf 1 2>/dev/null) GREEN=$(tput setaf 2 2>/dev/null) RESET=$(tput sgr0 2>/dev/null) fi

if [ -t 1 ]; then RED=$(tput setaf 1 2>/dev/null) GREEN=$(tput setaf 2 2>/dev/null) RESET=$(tput sgr0 2>/dev/null) fi

Here, tput setaf 1 sets the foreground to red (color index 1 in the standard 8-color palette), and the conditional ensures colors are only attempted if standard output is a terminal. Usage could then be: echo "${RED}Red text${RESET}". This approach falls back gracefully on non-supporting environments by leaving variables empty. For dynamic displays like progress bars, cursor control sequences from the Control Sequence Introducer (CSI) allow overwriting output without scrolling. A simple script might save the cursor position, update a bar on the same line using carriage return (\r) combined with CSI for erasure, and restore the position:

bash

# Save cursor position echo -ne "\e[s" for i in {1..20}; do # Restore, erase line, print progress progress=$(printf '%*s' "$i" '' | tr ' ' '#') echo -ne "\e[u\e[2K\r[${progress}$((20-i))%]" sleep 0.1 done echo # Newline to restore normal flow

# Save cursor position echo -ne "\e[s" for i in {1..20}; do # Restore, erase line, print progress progress=$(printf '%*s' "$i" '' | tr ' ' '#') echo -ne "\e[u\e[2K\r[${progress}$((20-i))%]" sleep 0.1 done echo # Newline to restore normal flow

The \e[s saves the cursor, \e[u restores it, and \e[2K erases the entire line, enabling in-place updates for visual feedback in supported terminals like xterm. Error handling in such scripts typically involves checking terminal capabilities to avoid garbled output in non-interactive or color-incapable sessions. The [ -t 1 ] test verifies if stdout is a tty, while tput colors can confirm color support (e.g., returning 8 or more for basic ANSI colors). An example wrapper function:

bash

colorize() { if [ -t 1 ] && [ "&#36;(tput colors 2>/dev/null)" -ge 8 ]; then echo -e "\e[31m&#36;1\e[0m" else echo "&#36;1" fi }

colorize() { if [ -t 1 ] && [ "&#36;(tput colors 2>/dev/null)" -ge 8 ]; then echo -e "\e[31m&#36;1\e[0m" else echo "&#36;1" fi }

This ensures fallback to plain text when ANSI codes are unsupported, maintaining script reliability across environments like pipes or dumb terminals.

Programming Language Integration

ANSI escape codes can be directly integrated into C programs using standard output functions from the <stdio.h> header, allowing developers to embed control sequences for formatting text in compatible terminals. For instance, the sequence \033[1;31m sets bold red foreground color, while \033[0m resets to default attributes. A simple example demonstrates this:

c

#include <stdio.h> int main() { printf("\033[1;31mBold red text\033[0m\n"); return 0; }

#include <stdio.h> int main() { printf("\033[1;31mBold red text\033[0m\n"); return 0; }

This approach outputs the escape sequences as raw bytes to stdout, which terminals interpret for visual effects like color and style changes. To abstract away direct escape code management and ensure portability across Unix-like systems, libraries such as provide higher-level interfaces for terminal control, including color handling via predefined pairs. initializes color support with start_color() and defines pairs using init_pair(), such as init_pair(1, COLOR_RED, COLOR_BLACK) to associate pair 1 with red text on a black background, followed by attron(COLOR_PAIR(1)) to apply it. These functions translate to appropriate ANSI sequences based on the terminal's database entry, supporting features like cursor movement and screen updates without manual sequence construction. For cross-platform development, particularly targeting Windows environments where native console support for ANSI codes is limited, PDCurses offers a implementation of the curses API that emulates Unix behavior on Windows consoles, DOS, and other platforms. PDCurses handles ANSI-compatible output through its functions, enabling the same color and positioning code to run portably without platform-specific adjustments in most cases. To achieve broader compatibility in pure code, developers use conditional compilation directives like #ifdef _WIN32 to enable virtual terminal processing on Windows via SetConsoleMode with the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag before outputting sequences, ensuring escape codes are processed correctly while falling back to direct writes on Unix systems. Programs can dynamically detect terminal capabilities to avoid incompatible sequences by querying the Device Attributes (DA) using the primary DA sequence ESC [ c (CSI c with Ps=0 omitted), which prompts the terminal to respond with its identification and supported features, such as VT100-level compliance. For example, a VT220-compatible terminal might reply with CSI ? 62 ; 1 ; 2 ; 6 ; 7 ; 8 ; 9 c. This query allows conditional use of advanced sequences, enhancing robustness across diverse terminals without assuming full ANSI compliance. For color support, secondary DA (CSI > c) can provide additional details on extended features.

Terminal Input Processing

Keyboard and Mouse Input Sequences

ANSI escape codes enable terminals to transmit keyboard and mouse events to the host application using Control Sequence Introducer (CSI) sequences, which follow the general form ESC [ followed by parameters and a final character. These input sequences allow applications to interpret user actions such as key presses and cursor movements without relying on raw character codes. For keyboard input, and other navigation keys are encoded using simple CSI sequences in . The up arrow key sends ESC [ A, the down arrow ESC [ B, the right arrow ESC [ C, and the left arrow ESC [ D. In application cursor key mode, enabled via the DECSET private mode ?1 h (DECCKM), these keys instead transmit Single Shift Three (SS3) sequences: SS3 A for up, SS3 B for down, SS3 C for right, and SS3 D for left. Modifier keys like Shift, Ctrl, Alt, and combinations modify these sequences by inserting numeric parameters before the final character; for instance, Ctrl+Up arrow transmits ESC [ 1;5 A, where 5 denotes the Ctrl modifier. Shift+Up uses 2 (ESC [ 1;2 A), and Alt+Up uses 3 (ESC [ 1;3 A), with higher numbers for combinations such as Ctrl+Shift+Up (6, ESC [ 1;6 A). Extended function keys F1 through F12 are represented using CSI sequences with tilde (~) terminators in PC-style keyboard mode. F1 sends ESC [ 11 ~, F2 sends ESC [ 12 ~, up to F12 sending ESC [ 24 ~. These can include modifiers; for example, Shift+F1 transmits ESC [ 1;2 P (using P as the final for F1 in some variants, though ~ is standard for higher keys), and Ctrl+F1 uses ESC [ 1;5 P. Alt combinations prepend ESC to the base sequence or use modifier codes like 9 for Alt in extended modes. Mouse input reporting is an extension beyond core ANSI standards, typically enabled through DECSET private modes to allow the terminal to send CSI sequences for mouse events. The VT200 mouse reporting mode (?1000 h) uses the X10 protocol format, where a button press or release at position (x, y) sends ESC [ M b x' y', with b as the button code (32 + button index 0-2 for left/middle/right press, 35 for release), and x', y' as 1-based coordinates plus 32 (as character codes). For more precise tracking, the button-event mouse tracking mode (?1002 h) reports presses, releases, and drags using ESC [ < b ; x ; y M/R, where < indicates the extended format, b is the button (0=left, 1=middle, 2=right, 3=release, plus modifiers), and x, y are cell-based positions; M for press, R for release. Motion is not reported in this mode unless combined with other settings. The SGR extended mouse mode (?1006 h), often referred to in contexts like SGR 1000 for compatibility, supports larger coordinates and distinguishes events: ESC [ < b ; x ; y M for button press and motion (b encodes button and state, e.g., 0-2 for press, 32+ for motion), and ESC [ < b ; x ; y m for release (b=0-2), allowing reporting of positions in terminals larger than 223x223 cells, with coordinates up to 2015. These modes can be disabled with ?1000 l, ?1002 l, or ?1006 l, respectively.

Response and Reporting Sequences

Response and reporting sequences enable applications to query terminals for operational status, device identification, and other attributes using Control Sequence Introducer (CSI) formats, with terminals replying via similar escape sequences read from standard input. These mechanisms, defined in standards like ECMA-48 and extended by DEC for VT-series terminals, facilitate dynamic adaptation of terminal behavior in text-based interfaces. Unlike control sequences that modify display state, reporting sequences elicit asynchronous responses to inform software about the terminal's configuration or position. The Device Attributes (DA) sequence requests identification of the terminal's type and capabilities. The primary DA query, sent as CSI c (or equivalently ESC [ c), prompts the terminal to report its architectural class and supported features in the format CSI ? Ps1 ; Ps2 ; ... c, where each Ps value indicates specific attributes such as VT level and options like 80/132-column support. For a VT100 terminal, the typical response is CSI ? 1 ; 2 c, where 1 denotes VT100 compatibility and 2 indicates support for additional modes like the Advanced Video Option (AVO). The secondary DA query, CSI > c (or ESC [ > c), elicits a response in the format CSI > Ps ; Pv ; Pc c, providing details on terminal ID (Ps, often 61 for VT220-like), firmware version number (Pv), and hardware options (Pc, such as 0 for standard keyboard). This sequence, introduced in later VT models, allows applications to detect version-specific capabilities without assuming a fixed terminal type. Cursor position reporting, known as Device Position Report (DPR) or Cursor Position Report (CPR), uses CSI 6 n (or ESC [ 6 n) to request the current cursor location, with the terminal responding as CSI Pn ; Pn R (or ESC [ Pn ; Pn R), where the first Pn is the row (line) number and the second is the column number, both 1-based. For example, if the cursor is at row 10, column 5, the response would be ESC [ 10 ; 5 R. An extended variant, CSI ? 6 n, supported in some DEC terminals, includes page information in the response CSI Pn ; Pn ; Pn R, though many implementations omit the page parameter. This reporting is essential for applications needing to track or restore cursor positions without visual assumptions. Mode queries, part of the Device Status Report (DSR) using CSI ? Ps n (or ESC [ ? Ps n), allow interrogation of specific DEC private modes, with responses indicating whether the mode is reset (0) or set (2). For instance, Ps = 1 queries the Cursor Keys Mode (DECCKM), which determines if cursor keys send application sequences (set) or ANSI cursor sequences (reset); the response is CSI ? 1 ; s n, where s = 2 for set or s = 0 for reset. Other Ps values query modes like keyboard action (Ps = 67 for DECKAUM) or numeric keypad behavior, enabling software to adapt input handling dynamically. These queries are particularly useful in emulators to verify compatibility with legacy behaviors. Version reporting is handled via the secondary DA sequence, as described earlier, where the Pv parameter in CSI > Ps ; Pv ; Pc c encodes the terminal's or software version in a numeric format, such as 20 for version 2.0. This allows applications to probe for supported features like extended character sets or reporting without trial-and-error. In practice, responses vary by ; for example, might return CSI > 83 ; 0 ; n c to indicate compatibility with version 0 and specific patches (n).

References

Add your contribution
Related Hubs
User Avatar
No comments yet.