Ral Vs Ansi Colors

[Jacquelyne Betance]

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. They are used in development, scientific, commercial text-based applications as well as bulletin board systems to offer standardized functionality.

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.

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.

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.

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.[5] 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.

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[6] and as an early PDF-like document storage format, the Open Document Architecture.[citation needed]

The IBM PC, introduced in 1983, 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 optional support with a device driver named ANSI.SYS. Poor performance, and the fact that it was not installed by default, meant software rarely took advantage of it. Some other systems did try to address the need for these sequences, many clones of DOS handled them without a driver, and OS/2 had an ANSI command that enabled the sequences.

The Windows Console did not support ANSI escape sequences, nor did Microsoft provide any method to enable them. Some replacements or additions for the console window such as JP Software's TCC (formerly 4NT), Michael J. Mefford's ANSI.COM, Jason Hood's ANSICON[7] and Maximus5's ConEmu interpreted ANSI escape sequences printed by programs. A Python package named colorama[8] internally interprets ANSI escape sequences in text being printed, translating them to win32 calls to modify the state of the terminal, to make it easier to port Python code using ANSI to Windows. Cygwin performs similar translation to all output written to the console using Cygwin file descriptors, the filtering is done by the output functions of cygwin1.dll, to allow porting of POSIX C code to Windows.

In 2016, Microsoft released the Windows 10 version 1511 update which unexpectedly implemented support for ANSI escape sequences, over two decades after the debut of Windows NT.[9] 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.[10]

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:

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.[21] Each display attribute remains in effect until a following occurrence of SGR resets it.[5] If no codes are given, CSI m is treated as CSI 0 m (reset / normal).

There has also been a similar but incompatible 88-color encoding using the same escape sequence, seen in rxvt and xterm-88color. Not much is known about the scheme besides the color codes. It uses a 444 color cube.

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,[13] KDE's Konsole,[35][36] and iTerm, as well as all libvte based terminals,[37] including GNOME Terminal.[38]

The syntax is likely based on the ITU's T.416 Open Document Architecture (ODA) and interchange format: Character content architectures,[34] 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:

Rather than using the color support in termcap and terminfo introduced in SVr3.2 (1987),[39] 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.[40][41] 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.[42]

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[41] 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.[43]

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).[13] For example, Xterm allows the window title to be set by ESC ]0;this is the window title BEL.

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.[47] However, appending ST will be ignored by Linux and form a proper, ignorable sequence for other terminals.[citation needed]

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.

c80f0f1006