ANSI escape code


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

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 character, a character, and then two characters representing numerical values equal to the x,y location plus 32. The Hazeltine 1500 had a similar feature, invoked using, 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 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 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. 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. In 1994, ANSI withdrew its standard in favor of the international standard.
The first popular video terminal to support these sequences was the Digital VT100, introduced in 1978. 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. 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 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.
ECMA-48 has been updated several times and is currently at its 5th edition, from 1991. It is also adopted by ISO and IEC as standard ISO/IEC 6429. 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. 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

In the early 1980s, large amounts of software directly used these sequences to update screen displays. This included everything on VMS, 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 and as an early PDF-like document storage format, the Open Document Architecture.

DOS and Windows

The IBM PC, introduced in 1981, did not support these or any other escape sequences for updating the screen. Only a few control characters 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. Poor performance, and the fact that it was not installed by default, meant software rarely 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, Michael J. Mefford's ANSI.COM, Jason Hood's and Maximus5's ConEmu enabled ANSI escape sequences. Software such as the Python colorama package 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. 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.
Windows Terminal, introduced in 2019, supports the sequences by default. Since Windows 11 22H2 and Windows Terminal 1.15, Windows Terminal replaces Windows Console as the default.

C0 control codes

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, making it part of the same standard as the C1 set invoked by the ANSI escape sequences. This is used to shorten the amount of data transmitted, or to perform some functions that are unavailable from escape sequences:
^C0AbbrC escape sequenceNameEffect
0x07\aBellMakes an audible noise.
0x08\bBackspaceMoves the cursor left.
0x09\tTabMoves the cursor right to next tab stop.
0x0A\nLine FeedMoves 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.
0x0C\fForm FeedMove a printer to top of next page. Usually does not move horizontally, though programs should not rely on this. Effect on video terminals varies.
0x0D\rMoves the cursor to column zero.
0x1B\x1B, \033EscapeStarts all the escape sequences

Escape sequences vary in length. The general format for an ANSI-compliant escape sequence is defined by ANSI X3.41. The escape sequences consist only of bytes in the range , 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

If the #ESC| is followed by a byte in the range 0x40 to 0x5F, the escape sequence is of type. Its interpretation is delegated to the applicable C1 control code standard. Accordingly, all escape sequences corresponding to C1 control codes from ANSI X3.64 / ECMA-48 follow this format.
The standard says that, in 8-bit environments, the control functions corresponding to type escape sequences can be represented as single bytes in the 0x80–0x9F range. 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, but no space is saved this way.
CodeC1AbbrNameEffect
Single Shift TwoSelect a single character from one of the alternative character sets. SS2 selects the G2 character set, and SS3 selects the G3 character set. In a 7-bit environment, this is followed by one or more GL bytes specifying a character from that set. In an 8-bit environment, these may instead be GR bytes.
Single Shift ThreeSelect a single character from one of the alternative character sets. SS2 selects the G2 character set, and SS3 selects the G3 character set. In a 7-bit environment, this is followed by one or more GL bytes specifying a character from that set. In an 8-bit environment, these may instead be GR bytes.
Device Control StringTerminated by ST. Xterm's uses of this sequence include defining User-Defined Keys, and requesting or setting Termcap/Terminfo data.
Control Sequence IntroducerStarts most of the useful sequences, terminated by a byte in the range 0x40 through 0x7E.
String TerminatorTerminates strings in other controls.
Operating System CommandStarts a control string for the operating system to use, terminated by ST.
Start of StringTakes an argument of a string of text, terminated by ST. The uses for these string control sequences are defined by the application or privacy discipline. These functions are rarely implemented and the arguments are ignored by xterm. 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.
Privacy MessageTakes an argument of a string of text, terminated by ST. The uses for these string control sequences are defined by the application or privacy discipline. These functions are rarely implemented and the arguments are ignored by xterm. 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.
Takes an argument of a string of text, terminated by ST. The uses for these string control sequences are defined by the application or privacy discipline. These functions are rarely implemented and the arguments are ignored by xterm. 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.