Talk:ANSI escape code

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.


How can a document with ANSI escapes be converted into a more portable form? I would like to send such a document, but the receiver has no ANSI terminal. -- Thomas Hafner — Preceding unsigned comment added by (talk) 14:00, 21 October 2003 (UTC)

I'm sure there are plenty tools on the web; I know a plug-in for FAR (File and Archive Manager); it can view the .ANS files and translate them to HTML format.

Also, there are also codes for terminal keys (F1-F12, PageUp/Down etc). Does anyone have a list of those codes?

-- Vladimir Panteleev — Preceding unsigned comment added by (talk) 00:18, 26 July 2004 (UTC)

F1 ^[OP F2 ^[OQ F3 ^[OR F4 ^[OS F5 ^[[15~ F6 ^[[17~ (This is not a typo) F7 ^[[18~ F8 ^[[19~ F9 ^[[20~ F10 ^[[21~ F11 ^[[23~ (This is not a typo) F12 ^[[24~

(Not so standardised) F13-F15 F13 ^[[25~ F14 ^[[26~ F15 ^[[28~ F13 ^[[1;2P F14 ^[[1;2Q F15 ^[[1;2R

F13 ^[[1;2P F14 ^[[1;2Q F15 ^[[1;2R -- George Orwellophile — Preceding unsigned comment added by (talk) 09:03, 8 May 2013 (UTC)

This is kind of DOS biased; also, a reference to ansi.sys documentation (for the dos-specific stuff) would be good, if any exists --Random832(tc) 08:29, 4 February 2007 (UTC)

Agreed. The article lacks a bigger picture - text terminals are only briefly mentioned and even the VT100 is totally omitted although it has had a lot of influence on the implementations of ANSI X3.64. A little bit of history wouldn't hurt, especially since the de-facto combination of standards has evolved over time. --Viznut 12:58, 4 February 2007 (UTC)

ISO 6429[edit]

The C0 and C1 control codes article says C1 control codes are defined in ISO 6429. ISO 6429 redirect to this article, ANSI escape code. But in this article, C1 control codes are not discussed. Does C1 have actually anyhting to do with ANSI escape codes? --Abdull 08:03, 8 June 2007 (UTC)

Answer to myself. According to the official ECMA-048 5th edition, ECMA-048 4th edition was adopted as ISO 6429 2nd edition. ECMA-048 5th edition was adopted as ISO/IEC 6429 3rd edition. ECMA-048 5th edition defines both the so called ANSI escape codes, as well as the C0 set (PDF page 22) and the C1 set (PDF pages 22, 23). By the way CSI can either be the true CSI character from the C1 set, or be a 7-bit safe sequence of ESC character plus [ (bracket, ASCII 0x5B). --Abdull 10:09, 8 June 2007 (UTC)

Display codes[edit]

This article only covers display codes. ANSI X3.64 covered any output device, but was fairly open about implementation. Many printer companies used variations of ANSI over the years— Digital, Texas Instruments, Printronix, Tally, GENICOM and more. --— Gadget850 (Ed) talk - 21:44, 8 December 2007 (UTC)

Perhaps, with appropriate sources. The only printer controls I recall well are the PCL ones, which are not ANSI Tedickey (talk) 22:21, 8 December 2007 (UTC)

Is there any merit in linking to Mud eXtension Protocol (MPX) given that that uses a CSI with a single Ps argument and a final character of z for a Multi User Dungeon (MUD) game server to control what subsequent HTML-like tags are interpreted by the MUD Client?  Especially as some of those tags are used to control the display of information.  Though the originator was Zuggsoft the author of the zMUD and cMUD MUD clients, it is now present, even if not robustly so (there have been some ambiguities in both the protocol and how the originator interpreted and implemented it in his own projects) in a number of MUDs and other clients. --SlySven (talk) 01:29, 29 March 2015 (UTC) (currently a developer for the F.O.S.S. Mudlet MUD client)

Mud eXtension Protocol (MPX) links to a disambiguation page. Perhaps you meant the redirect to MXP (computing), in turn to, which does appear to contain part of the information you mentioned -- but "a number of MUDs" needs some reliable source (third-party of course) TEDickey (talk) 01:39, 29 March 2015 (UTC)

The ANSI brown/orange/yellow color and IBM CGA hardware[edit]

As for the footnote about the color of brown, it would be worth providing a link to the Color Graphics Adapter article.

In that article, it mentions that the color of brown was a special case in hardware. IBM added circuitry to early CGA monitors to force the color to be orange/brown/rust, instead of an unpleasing dark yellow. The CGA article explains more about this.

Not all early PC clones did the same CGA monitor hack that IBM did. Therefore, there is evidently a lot of variation in the industry, about what that color should be.

I edited the article to include this link, unless there's a good reason to not do so. I could not find solid evidence that ANSI color codes were tied to the IBM CGA hardware design, but they sure seem similar. It's obvious that the 16 available ANSI colors have a 1:1 mapping to available IBM CGA colors, but they appear in a slightly different order. If proof can be found that ANSI colors were based on CGA colors, or vice versa, please add this to the article.

--Kreline (talk) 21:37, 11 August 2008 (UTC)

Thank you for the reference. I knew dim yellow was really orange/brn, but didn't know why and from where before. Davygrvy (talk) 08:37, 27 January 2009 (UTC)

Category: User Interface Techniques[edit]

This article should not be inside that category. Please check the main article on User interface technique for a clarification. Dragice (talk) 19:09, 5 September 2008 (UTC)

Of course I disagree. You're asserting that ANSI escape codes are not (for example), used to render visual effects for user interfaces. Tedickey (talk) 19:54, 5 September 2008 (UTC)

I'm sorry, but this still does not fit the definition of user interface technique. ANSI escape codes are not user interface techniques at least for two reasons: 1) they only involve output 2) they are at the system level -- the user does not see them. Please take some time to read the article. Dragice (talk) 23:10, 5 September 2008 (UTC)

I read the article (which is both vague and oriented toward one viewpoint). Compare against User interface. I also note the inconsistency between your remarks and the inclusion of Modifier key, Scrolling, Pie menu. Tedickey (talk) 23:27, 5 September 2008 (UTC)

I took a closer look at the article and I admit that directly typing ANSI escape codes in a terminal in order to clear the screen or to move the cursor can be considered as an interaction technique. But is this really the way people use ANSI escape codes? Or is it more a file format for attributed text? It's not clear from the article. This article is extremely technical and I'm afraid most of its current content is irrelevant to human-computer interaction. If you are willing to do something about it, then I'd be happy to see ANSI escape codes listed as a user interface technique. However, please note that in case ANSI escape codes are not intended to be used in interactive mode, it would not make sense to list them in that category. No more than HTML and other languages. Dragice (talk) 20:35, 13 September 2008 (UTC)

Generally, most people interested in the ANSI codes are using them as literal strings in their (shell) command prompt (or similar uses). That's in spite of higher-level interfaces, e.g., tput for UNIX systems. There's technical information here because that's what the topic covers. Given the current category composition, it's more interactive than syntax highlighting Tedickey (talk) 20:47, 13 September 2008 (UTC)

"ANSI escape code" vs "ANSI escape sequence"[edit]

Comments regarding "correctness" are misplaced - "code" is applicable, but more generic. Tedickey (talk) 00:49, 2 January 2009 (UTC)

"Franktur vs Fractur"[edit]

Shouldn't Franktur be Fraktur? Wikipedia appears to have chosen the second for other articles. (talk) 22:54, 3 March 2010 (UTC)

yes - ECMA-48 agrees it should be Fraktur Tedickey (talk) 00:15, 4 March 2010 (UTC)


The standard doesn't give a definition for SGR 38/48. A better way to express that might be as a footnote pointing out that some commonly-used terminals starting with xterm interpret this as a selection from a color palette, e.g., 88- or 256 colors. As it stands, the table entry is incorrect since it is discussing the standard's definitions rather than a particular interpretation TEDickey (talk) 09:50, 30 November 2010 (UTC)

It seems that these sequences were based on a misinterpreted standard. [1] [2] (talk) 03:56, 29 December 2010 (UTC)
You're referring to this (which is itself partly inaccurate, e.g., claiming that certain information is in ECMA-48):
+A note on conformance
+These ESC codes break the "associativity" of SGR, but after some
+research the result is, that the standard itself is broken here.
+The perhaps best codes due to ECMA-48 would probably be e.g.
+38:2:<r>:<g>:<b>, i.e. consistently a colon instead of a semicolon.
+But apparently, this is defined different in ISO-8613 (which is
+included at this place in ECMA-48), actually breaking ECMA-48.
+We cannot help this and implemented the codes as above, which
+is a balanced decision.
An alternative would be to annotate it like has been done for 90-109 by putting the text '(not in standard)' in the notes section. Either way, even if it isn't in the standard, it is highly prevalent as pretty much every xterm compatible terminal emulator supports it.Ferroin (talk) 15:39, 27 February 2012 (UTC)

There's some discussion which you may find in one of the KDE mailing lists which mentions the fact that the standard which would apply in that area was not freely available (cost perhaps $200US to get a copy), and not being widely used is moot TEDickey (talk) 13:35, 29 December 2010 (UTC)

How is this dubious? It says exactly how it works. Here's a test. (Yes, that's not xterm-256color, it's iTerm2, which follows the same rules.)

IMHO SGR 38/48 has little to do with xterm, although (as mentioned previously in the discussion) xterm has done a non-conforming implementation of these sequences. The CCITT T.416 standard, which Ecma-48 refers to regarding the intended use of SGR 38/48, defines the proper use of the sequences. Further, the colons used in T.416 causes problems in Ecma-48, possibly breaking the standard, but nevertheless, shouldn't the article mention the T.416 definition and the fact that it's broken and just skip mentioning the xterm implementation? — Preceding unsigned comment added by (talk) 21:20, 3 December 2011 (UTC)

well, currently the closest in that table to being the same case is the last two lines dealing with aixterm. Those codes aren't in ECMA-48 TEDickey (talk) 22:07, 3 December 2011 (UTC)
ISO Store still wants about $200 for a copy. But Google finds a copy of CCITT T.416 (from 1993) here, simplifying discussion. TEDickey (talk) 00:53, 6 December 2011 (UTC)
That link seems to be broken, but I found a working one here, under "Access : Freely available items": — Preceding unsigned comment added by (talk) 03:15, 25 June 2013 (UTC)

A little chaotic[edit]

Sorry, but the article is somewhat chaotic. I have learned the ANSI codes time ago, but it takes me nearly 30 minutes to find out how to set a certain color from the information in the article. Guess how long a total uninformed person would take... -- (talk) 00:56, 26 March 2011 (UTC)

Standard library?[edit]

Is there a standard library for using the ANSI terminal escapes? Dread Lord CyberSkull ✎☠ 03:04, 25 April 2011 (UTC)

Never mind, I missed that section. Dread Lord CyberSkull ✎☠ 03:06, 25 April 2011 (UTC)

use of source known to be inaccurate[edit]

The source mentioned is inaccurate in more than one part - color is one of the first three sections with errors which meet the eye (fonts has missing text, making it worthless, while define-key doesn't correspond to any model of vt100). There are scattered errors in display attributes - "hidden" isn't vt100 - erasing - the comment about cursor movement, as well as some questionable content in printing). I've known about this source for "a while". When I first encountered it, it apparently was the work of "Robert M. Free", which you can find in other locations, with his copyright notice 1996. This copy doesn't have the copyright. However long I've known about it (say ten years), I've found no use for the content whatsoever. (The author is not well-known, and he's not taken the time to antagonize me - though there's an amusing bug report where someone else took it seriously...). contains factual information, so does Shuford's recently-defunct website. TEDickey (talk) 20:44, 16 August 2011 (UTC)

For instance this copy TEDickey (talk) 20:52, 16 August 2011 (UTC)

It sounds like this reference is useless. I agree it is showing sequences that the VT100 did not do (it could not change color). It would be nice to find an actual reference that just says "The VT100 was first made in 1978 and supported ANSI Escape sequences". Same for the H19.Spitzak (talk) 21:44, 16 August 2011 (UTC) TEDickey (talk)

For two character sequences the second character is in the range ASCII 64 to 95 (@ to _)[edit]

Wrong. On linux (when capslock is off) Alt+A sends "27 97" which is two character sequence, but second character is not in range 64..95. When capslock is on it sends "27 65". — Preceding unsigned comment added by (talk) 23:20, 17 September 2011 (UTC)

However, you're talking about a sequence sent by the keyboard, which is not topical here. The relevant content would that described in console_codes manpage TEDickey (talk) 23:30, 17 September 2011 (UTC)

Example of use in shell scripting[edit]

The given example and presentation is Linux-specific, probably doesn't add much value to this topic. The script example by the way is highlighted inconsistently. TEDickey (talk) 20:58, 27 October 2011 (UTC)


I came here trying to interpret the codes handed to me by an obsolete piece of hardware. Decades ago I knoew from the top of my head what ESC-H or ESC-F or ESC-J were -- these days I figured I'd look it up. Turn out the article merely tells me that ESC-* exists (and that there's some range to the valid contents of "*") but there's no list or table telling me what those codes are. Lame. — Preceding unsigned comment added by (talk) 01:02, 29 October 2011 (UTC)

What is a single-character CSI (155/0x9B/0233)?[edit]

Regarding the edit I have done on 19:12, 29 October 2011 (UTC). It was reverted by TEDickey as it appears to be incorrect and lack a verification in a reliable, published source. The edit was: `There is a single-character CSI (155/0x9B/0233) as well.' -> `There is a single-character termination code (155/0x9B/0233) as well.' The reference is -> References -> 2nd reference == Quoting `The terminator "\007" is a problem area. Xterm historically uses this character, though it is non-ANSI. The "correct" character should be a "\233" string terminator, or "\033\\", which is the 7-bit equivalent. Modern xterm recognizes either (the "\007" or string terminator); waiting for the first of these.' — Preceding unsigned comment added by (talk) 20:32, 29 October 2011 (UTC)

Per ECMA-48, CSI is "control sequence introducer". Most of the sequences discussed in this topic begin with CSI. It has no meaning outside of that context. "String terminator" is something different. It is used to end certain sequences. TEDickey (talk) 20:48, 29 October 2011 (UTC)

sparked a variety of "clones,"[edit]

The vt100 did have imitators, but the given sources don't address this, since they don't mention the relationship TEDickey (talk) 21:09, 4 November 2011 (UTC)

ls syntax[edit]

I originally edited ls-color=always to be ls --color=always, but undid it on retrospect. I know 'ls --color=always' is the correct syntax for gnu ls, but felt that I should comment since it was specified as Unix style. Should this be changed? I feel that gnu ls is more common if the syntax is indeed different. — Preceding unsigned comment added by (talk) 01:08, 20 December 2011 (UTC)

The space is certainly necessary. I think any alternative to GNU is going to use a 1-letter switch but cannot find any indication what that may be. The "always" is not needed. I will revert the text.Spitzak (talk) 05:49, 21 December 2011 (UTC)
FreeBSD ls implements -G, which is used by GNU ls for a different purpose. Mac OS X uses the same code (though its manpage suggests that it is from an older version than FreeBSD, which originated this option). ("-G" is not mentioned in the standard, as I recall. Standard ls does not mention color.) A chief difference between the two implementations is that GNU ls uses neither termcap nor terminfo, and makes assumptions about color behavior which limits it to a subset of what a termcap/terminfo application would do, while FreeBSD ls uses termcap. TEDickey (talk) 09:57, 21 December 2011 (UTC)

assertion about C1 controls in UTF-8[edit]

C1 controls are defined by ECMA-35, which doesn't know anything about UTF-8. The statement in question implies that there is standard behavior (unsourced) and that there are terminals (plural) which follow this standard (or convention), also unsourced. As usual, lacking a source the entire statement should be removed TEDickey (talk) 01:10, 21 June 2012 (UTC)

The C1 controls are part of the Unicode standard. In particular CSI (Control Sequence Introducer) is defined as character U+009B. So the article is entirely correct. (talk) 23:01, 14 July 2012 (UTC)

See above: the Unicode standard defines code-points, but doesn't define behavior of control sequences such as described in this topic. TEDickey (talk) 23:45, 14 July 2012 (UTC)

I had the same question too. I will ask the Unicode forum about this topic, but for now I just can say Unicode defines encoding (UTF‑8, UTF‑16 and UTF‑32) which applies for transmission, and nothing in the Unicode standards (which I've read in large parts) says control code‑points should not be encoded the same way as other code–points. On the opposite, it explicitly states if a stream use an Unicode encoding form, then the whole stream must be encoded in that form, otherwise the whole stream is invalid. As I understand it, these are two different layers, and one may compare this with TCP/IP and HTTP: TCP/IP is for transmission and HTTP is what's transmitted over TCP/IP, and HTTP headers and data are both subject to transmission over TCP/IP, not only the data or only the headers. Anyway, I will ask the Unicode forum and will be back here as soon as I get an authoritative answer there. --Hibou57 (talk) 06:05, 12 April 2013 (UTC)
That's half of the question. The other half regards the unspecified terminals which are implied to encode C1 as UTF-8. TEDickey (talk) 08:17, 12 April 2013 (UTC)
I ran a test on kterm and it handles the UTF-8 encoding of CSI as the start of the escape. A raw CSI code is handled as an error and prints an error box. I also tried xterm and the UTF-8 encoding of CSI was ignored as though it was an unknown control character, while a raw CSI was turned into an '@' character that it used for all encoding errors. Would be interesting to try some other terminal emulators, but it looks like the CSI must be UTF-8 encoded.
Though raw CSI bytes could be interpreted by a terminal and cannot possibly be confused with UTF-8 (as they are a code for continuation bytes), there are still going to be problems with storing them in strings that are sent to be printed. Raw bytes would work, but in many cases the string is passed through or produced by a system that can only handle valid UTF-8 encodings, making it impossible to produce the raw CSI.Spitzak (talk) 00:51, 13 April 2013 (UTC)
You appear to be confused in some respect about xterm (it's one of those features that people comment on occasionally - see and for instance). For kterm - I don't recall that it knows about UTF-8 - it is an ISO-2022 terminal (unless you're confusing the name with konsole, perhaps). TEDickey (talk) 02:04, 13 April 2013 (UTC)
Those documents seem to match exactly how I am seeing xterm work. You are right I meant konsole, not kterm. I have tried a few more terminals and have not found any that interpret a raw CSI (by "raw CSI" I mean a single byte with the value 0x9b). I have only found two that interpret a UTF-8 encoded CSI (meaning the two bytes 0xc2,0x9b): konsole and the Linux console. So the conclusion is that the text saying a CSI takes two bytes in UTF-8 is correct, imho.Spitzak (talk) 18:39, 13 April 2013 (UTC)
I just tested that statement using konsole 2.4.5 (it does not honor CSI translated to UTF-8). Linux console behaved as you suggest, but its C1 controls don't work, as noted quite a while ago in discussion of vttest. Still, a WP:RS is needed - I don't believe you can produce one. TEDickey (talk) 19:36, 13 April 2013 (UTC)
Minor correction: Linux console simply ignored the translated CSI in my quick check - it did not actually interpret it. TEDickey (talk) 19:38, 13 April 2013 (UTC)


Can someone explain the 'Fraktur' option a bit more. Judging by the article it is linked to, it selects a gothic font but I've yet to see gothic fonts on any terminal or emulator from 1980 onwards. Thanks.  Stepho  talk  05:43, 14 May 2013 (UTC)

ECMA-48 (fifth edition June 1991) says "Fraktur (Gothic)" but offers no explanation. TEDickey (talk) 08:29, 14 May 2013 (UTC)

Sigh :( But thanks for the reply anyway.  Stepho  talk  11:07, 14 May 2013 (UTC)


At least on Linux here it appears that the order does not matter; the terminal software (e. g. xterm) will pick out what is reasonable for an ANSI sequence. For example, printf "\033[07;35m" and printf "\033[035;7m" will produce the same result at least here. Though not necessarily everywhere, I'd assume. -andy (talk) 13:17, 19 August 2013 (UTC)

That's because 7 (inverse) and 35 (magenta text) are unrelated attributes. printf "\033[035;36m" (select magenta text, then cyan text) would look quite different to printf "\033[036;35m" (select cyan text, then magenta text).  Stepho  talk  13:31, 19 August 2013 (UTC)


A number of printers have used the ANSI emulation over the years. With obvious differences between a video terminal and a printer, there are different commands and similar commands are implemented differently.

Sequence Meaning
CSI or ESC [ Control Sequence Introducer
CSI p1 p2 SP ~ GENEMU: Selects emulation
ESC [p1 ; p2 SP B GSM: Modifies vertical (p1) and horizontal (p2) character size
ESC [p1 ; p2 SP G SPI: Sets lpi (p1) and/or cpi (p2) in decipoints
ESC H HTS: Sets a tab at current print position
ESC J VTS: Sets a tab at current paper position
ESC K PLD: Moves print line down 3/72 inch (subscript)
ESC L PLU: Moves print line up 3/72 inch (superscript)
ESC P DCS: Introduces dot graphics
ESC [ p1 a HPR: Moves print position right p1 distance (relative)
ESC [ p1 b REP: Dot graphics: repeat preceding character p1 times
ESC c RIS: Resets printer to a known initial state
ESC [ p1 d VPA: Sets vertical position to p1 decipoints or lines
ESC [ pl e VPR: Moves paper forward p1 decipoints
ESC [ p1; p2 f HVP: Moves paper and print position (absolute)
ESC [ p1 g TBC: Clears tabs: p1=3 for horizontal
ESC [ p1 ; ...; pn h SM: Set mode (PUM, LNM, proportional, character mapping)
ESC [ p1 j HPB: Moves print position left by decipoints or columns
ESC [ p1 k VPB: Moves paper backward by decipoints or lines
ESC [ p1 l RM: Reset mode (PUM, LNM, proportional, character mapping)
ESC [ p1; ... pn m SGR: Selects font styles and enhancements
ESC [ p1 p2 ! p GENVF2: EVFU vertical paper movement command
ESC [ p1 ; p2 ; p3 q GENGRM: Selects graphics horizontal and vertical dot densities
ESC [ p1; p2 ; p3 r GENFD: Sets form length (pl), margins: top (p2), bottom (p3)
ESC [ p1; p2 s GENSLR: Sets margins: left (p1), right (p2) in decipoints
ESC [ p1 t Selects bar codes p1=3, quit bar code p1=0
ESC [ p1 ;... p12;v GENVTS: Sets vertical tabs (p1, etc.) in decipoints or lines
ESC [ p1 x GENSNC: Selects international character sets
ESC [ p1 ; ...; p10 } Selects bar code parameters
ESC [ p1 SP } GENDFC: Download Font Control: Checks printer for downloaded font
OSC or ESC ] Operating System Command: introduces sequence
ESC ] 5 BFL (Begin Font Load): Valid only if download option is installed.
ESC ] ! Begins 12-channel EVFU table loading
ESC \ ST: String Terminator. Exits special modes
ESC [ p1 ` HPA: Horizontal Position Absolute
OSC 9 ; p1 ; ... ; p8-pn ST Character Map Load
5000 Series Programmer's Manual (PDF). GENICOM. GEK-00031B. 

See page 16 for the GENICOM ANSI, page 155 for DEC LGplus and page 195 for DEC PPL3 emulations. --  Gadget850 talk 12:58, 21 August 2013 (UTC)

24-bit colors (sic)[edit]

Neither of the links provided for the comment about 24-bit colors in konsole is relevant to the statement which they are nominally supporting. TEDickey (talk) 13:04, 7 September 2013 (UTC)

not ANSIS.SYS[edit]

Those links are clutter, since ANSI.SYS implements such a small fraction of ANSI to begin with TEDickey (talk) 20:29, 15 September 2013 (UTC)

Amiga versus ANSI versus DEC[edit]

Looking at the suggested source, none of the codes appear to be DEC-specific: there are no DEC-specific sources of information cited on the page. Perhaps the proponent of the source can point out the features which have a reliable source - comments in a wiki fail that criteria - otherwise the comment about DEC can be deleted. A reliable source of course would be WP:Verifiable. Most of the controls are Amiga-specific or from some unidentified source; a small fraction is "ANSI". TEDickey (talk) 19:18, 10 July 2014 (UTC)

mIRC colors[edit]

The developer's documentation at makes it clear that the program relies upon terminal emulators to render the actual colors. Lacking reliable source (no second-hand, anonymous comments), there is no reason to add it to this topic TEDickey (talk) 09:24, 23 December 2014 (UTC)

You obviously misread the document. The program doesn't rely on terminal emulators to render actual colors IN mIRC. It's explaining to the mIRC user that other terminal emulators are going to see slightly different colors than they are -- that different terminals use different colors. The very nature of my edit. (talk) 14:23, 23 December 2014 (UTC)


I concur with @ to this extent: mIRC is a Windows GUI program. It doesn't use a terminal emulator to put text on the screen; it renders its own text. I believe that what is being warned about is that when you are using mIRC and you send text strings that include the mIRC color coding sequence (ctrl-K, etc.) to IRC channels or users, that IRC users who are using a text-mode IRC program in a terminal emulator may see other colors. (Or none at all. It's not clear to me whether the ctrl-K sequence is a standard IRC thing, or just a property of mIRC and PIRCH.)

Well, that's fine. But, @, re your extraordinarily non-civil suggestion here, I did try it. Per your suggestion, I built a string containing $chr(27) followed by [1,31mDerp! .

alias ctest {
  %thestring = $chr(27) $+ [1;31mDerp!
  echo %thestring

On executing this alias I see


in the message window. This btw is with mIRC 7.38, the latest released version. The left arrow is of course the graphic associated with character number 27(decimal) in code page 437, which is what mIRC uses. So, the chr(27) is being handled as desired. But mIRC is clearly not interpreting the string as an ANSI escape sequence, even though it's a properly formatted one.

Also, there is no mention of ANSI escape sequences in the mIRC help, except for the $ansi2mirc identifier. Which exists so that you can turn text that was built to use ANSI escape sequences into something mIRC will display. You see, this identifier exists because mIRC doesn't interpret ANSI escape sequences in its displays: If you get text that includes such sequences, you have to run it through $ansi2mirc before mIRC will display it as the ANSI sequences intended.

What am I missing? Is there a way to set mIRC message, channel, etc., windows to interpret ANSI escape sequences instead of just displaying ESC as a left arrow? (And is there a reliable source that documents this ability? One's own experiments with "mirc.exe" don't count; that's WP:OR.)

If not, my edit (i.e. removal of your addition to the table) and its rationale stand: mIRC text display does not interpret ANSI escape sequences... which are the topic of this article... so mIRC's color codes don't belong here.

The document linked by Tedicky confirms this. There is no mention of the ANSI SGR sequence there, or of any other ANSI escape sequence for that matter, only of mIRC's familiar ctrl-K code: "The color codes in mIRC are inserted by using the Control+K key combination. The actual control character inserted in the text is ascii character 3, seen as ^C or inverse C on most UNIX clients. The syntax of the color attribute in text has the format ^CN[,M]." This is clearly not describing anything resembling an ANSI escape sequence. Jeh (talk) 19:51, 23 December 2014 (UTC)

My initial comment was based on the IP-editor's claim that the application uses ANSI sequences. There are none mentioned on the page which the vendor provides for the program (unless they show further involvement and tune it to help). Looking closer, the program is implied to be a native Windows application - there is no terminal emulator involved. So that means that it is limited to providing some rendering of IRC. The relevant RFCs do not mention color:

What I find from reading is that there is no standard for IRC colors, but rather a convention. The cited page gives an informal description of it. None of the examples have any relationship to ANSI escape sequences, any more than escapes interpreted by an "echo -e" do. Here are a few other links discussing colors used with IRC clients:

Perhaps what we're seeing here is some promotional editing for a new release of mIRC, not yet available. Seeing the vendor's page change immediately after the dispute began makes that appear the most likely explanation TEDickey (talk) 00:27, 24 December 2014 (UTC)

Tedikey, what change to what website? No I am not the vendor nor related to the software in any capacity. I did post this, however, I see no changes have been made per my suggestion. Where are you looking?
  • (talk) 02:04, 24 December 2014 (UTC)
It's a commercial product - I'm not going to verify something of that nature without a third-party, freely-accessible reliable source. Find one if you want to discuss the issue. TEDickey (talk) 01:46, 24 December 2014 (UTC)
mIRC receives ANSI colors, and mIRC colors, using the same color table as I provided in the article. Test by sending the ANSI string to yourself via /msg. The RFCs don't mention ANSI because it's a different layer of protocol; just as the Telnet RFC makes no mention of ANSI. (a single user license costs $20). A review posted on Wikipedia is not a WP:RS, a review of the product which I would post elsewhere would be be useful to you in any way. TEDickey (talk) 01:54, 24 December 2014 (UTC)
I don't understand what you're getting at. mIRC has been around since 1995. You're suggesting that any software that isn't FOSS cannot have meaningful standards or impact to users and other systems in the wild? What about BeOS? Or Microsoft Windows? We're talking about a 20 year old piece of software that has has both contributed to and adhered to the same standards for the course ... so WP:RS has been satisfied. ~ (talk) 02:31, 24 December 2014 (UTC)
@ But your "RS" still doesn't support your claim. I have tested mIRC as you described, and posted the results above. mIRC does not interpret the ANSI SGR sequence. It simply renders the ESC character as character number 27 from Code page 437 (a left-pointing arrow) and then passes the rest of the "escape sequence" on to the output window as text, and there is no color change. So any claims that mIRC implements ANSI escape codes for color change are going to need a lot more than your assertions.
btw, you can't simply "send the ANSI string to yourself via /msg" in mIRC because mIRC will close the window you're typing in the moment you hit the Escape character. Your suggestion to try that implies strongly to me that, despite your bluster, you've never actually tried it. The mIRC control sequence for changing colors is absolutely not an ANSI escape sequence. It is ctrl-K followed by the foreground color code, optionally followed by a comma and the background color code, and then another ctrl-K.
Nor does the mIRC ctrl-K sequence use the same color numbers as the ANSI table. In the mIRC sequence, 0 is white, 1 is black, 2 is blue, 3 is green... and there are 16 color numbers, not just 8. So I see no basis for your claim that "mIRC receives ANSI colors, and mIRC colors, using the same color table as I provided in the article". The mIRC color codes don't use the same color table, and mIRC doesn't interpret ANSI SGR sequences at all (regardless of color table).
IF two people were running character-mode IRC clients (not mIRC) in terminal-emulator programs or windows, and IF those programs or windows implemented the ANSI SGR sequence with support for the standard colors, and IF the IRC clients passed the ESCape character through from one end to the other... then yes, one user could type an SGR sequence and the other would see the rendition change. But that's not "IRC supporting the ANSI SGR sequence", it's just IRC clients passing typed characters through from one end to the other. The interpretation of the color codes would be a function of the terminal emulator at each end of the link, not of the IRC client programs. So in the table in this article, we would not list the IRC client programs, but we might list the terminal emulators if their implementation of ANSI SGR was notable enough.
I am not seeing any clear line of argument in your last reply. FOSS has nothing to do with anything other than the free availability of the software to test. Microsoft Windows no longer ships a terminal emulator, but its character mode window does not implement ANSI escape sequences, for whatever that is worth. So far we have only your assertion that any implementation of IRC actually implements ANSI terminal control escape sequences in any form whatsoever (as opposed to simply passing them from end to end). Nor do I see any relevance in the fact that mIRC has been around for 20 years (so has the MS Windows character mode window, after all).
My position stands: since this article is about ANSI escape sequences, and mIRC does not implement ANSI escape sequences, mention of mIRC does not belong here (except perhaps in the list of programs that don't implement them). ("Windows XP CMD" shouldn't be in the table either.)
Now, if we had an article titled something like "Rendering of standard-named colors in various text-oriented programs," then we could certainly mention mIRC there. But not here. Jeh (talk) 07:02, 24 December 2014 (UTC)
I would leave "standard" out of that suggested title, since there are no standards as such which relate to IRC with colors (none that I was able to find, at any rate). Focusing on reliable sources in the form of non-anonymous, third-party reviews of the topic is the way to go. TEDickey (talk) 09:11, 24 December 2014 (UTC)
//msg $me $chr(27) $+ [1;31mDerp!

Sorry about the extraneous methodology, but I want to make sure that you get a good copy through here and absolutely repeatable and reliable results. Yes, mIRC has always rendered or emulated ANSI control sequences. You keep on bringing up mIRC's own Ctrl+K flavor of color encoding as well; I don't know why. It's allowed to support more than one encoding, right? UTF-8 is also supported. Lets never mention Ctrl+K again and lets talk about ANSI, because you guys keep getting distracted. (talk) 09:15, 24 December 2014 (UTC)

So far, you have not provided any useful information. TEDickey (talk) 09:18, 24 December 2014 (UTC)
I provided the useful information on the article page. The color comparison is useful because people actually seek out these comparisons to understand how various terminal environments receive colors when deciding on how to write their own software or before they transmit those colors. Indeed, the author of at least one Android IRC client sought this information from an mIRC help channel, and referenced this article in their research for color support. It's the very reason I put it here. You say I have not provided any useful information; I say you have not provided an environment congruent to useful information. (talk) 09:22, 24 December 2014 (UTC)
What do you mean, "Various terminal environments"? mIRC is not a terminal emulator program. That's another reason it doesn't belong in the table.
Also, "it's useful" is not sufficient for inclusion in Wikipedia. How-to guides and manuals are both useful, but Wikipedia is not supposed to contain either sort of info (see WP:NOTHOWTO, WP:NOTMANUAL). Even ignoring those, just how many people need to implement IRC clients?
The test with //msg worked, but I do not think it proves what you think it proves. I think mIRC is using its $ansitomirc function on your input, such that the stuff that goes to the server (and then back to the recipient user) has been converted to the IRC ctrl-C convention. As I previously demonstrated, mIRC does not properly render the ANSI SGR escape sequence in incoming text. It just displays the ESC as a "funny character" (as it does most of the other characters from 0 through 31). Jeh (talk) 12:04, 24 December 2014 (UTC)
mIRC is a terminal emulator for exactly this reason, it emulates ANSI. You say it doesn't properly render ANSI SGR escape sequences in incoming text; but you are wrong. It absolutely renders ANSI SGR escape sequences in incoming text, but not on outgoing text, which is intentional, so to allow the user to see the "funny characters" they're typing (which may very well change in the future; it's not incapable, just not desired apparently). You say that mIRC converts ANSI to its own flavor of ^c codes when a user inputs ANSI; This is also incorrect. When you send an ANSI escape sequence, it gets sent to the server untouched and other users see the same ANSI SGR you typed. When another user sends an ANSI sequence, mIRC sees and emulates it into color as well. The only thing it does with ^c is when you attempt to copy colored text to your clipboard, it converts it $ansitomirc from your chat buffer. If you want to observe what goes on under the hood, type: //debug -p @debug (talk) 22:17, 24 December 2014 (UTC)
"mIRC is a terminal emulator for exactly this reason, it emulates ANSI." Wrong. A terminal emulator is a program that emulates an interactive terminal such as a VT100. Such a program presents a display that acts like the emulated terminal and sends and receives characters through a serial port, a TELNET connection, or similar at the other end. If mIRC was a "terminal emulator" then there would be mIRC commands to open COM1 and type AT commands at my modem - or to TELNET to an appropriate server. Whether or not a terminal emulator implements ANSI is irrelevant to whether it's actually a terminal emulator; there were dozens if not hundreds of models of terminals that had their own non-ANSI control sequences and many of them are emulated by terminal emulator programs.
" You say it doesn't properly render ANSI SGR escape sequences in incoming text; but you are wrong. It absolutely renders ANSI SGR escape sequences in incoming text" -- then why didn't it do so in my test with echo? Clearly the ESC was there in the incoming text. But mIRC just displayed it as character 27 from code page 437 (which is how I know it was there....) You keep ignoring this point.
I see what you're seeing with the /debug output, but I don't believe that is definitive, nor does it correlate with your claims about incoming or outgoing text. The very function name $ansitomirc tells you that ansi is not mIRC's "true" or "internal" representation.
I would support the removal of this table to an "all table" article, "Table of color renderings by software" or some such. Then there would be no question of including mIRC, or the Windows command prompt for that matter. As it is I don't think the table has much to do with "ANSI escape codes", but rather the properties of various programs. Jeh (talk) 22:49, 24 December 2014 (UTC)
Would you agree that IRC takes place over a TELNET connection, and indeed most IRC clients (Irssi, XChat, Weechat, etc) are run from the terminal through a terminal emulator? mIRC is a Windows solution to this, bundling the IRC client into its own bare bones terminal emulator. Via simple script addons, mIRC can also connect to standard TELNET (23) and MUD/MUSH/MOO multi-user dungeons without any fancy coding. (talk) 23:23, 24 December 2014 (UTC)
"IRC takes place over a TELNET connection"?? Absolutely not. I don't see how anyone familiar with the two can entertain such a notion. From the Telnet article: "Telnet is still sometimes used in debugging network services such as SMTP, IRC, HTTP, FTP or POP3 servers, to issue commands to a server and examine the responses, but of all these protocols only FTP really uses Telnet data format." You appear to be claiming that an IRC client connects to a telnet server. That's ridiculous.
Now, someone might telnet into a remote system and run a text-mode IRC client on the remote system... but that's not "IRC taking place over a TELNET connection". The IRC protocol in that case doesn't travel between the remote system and the user's machine. Jeh (talk) 00:19, 25 December 2014 (UTC)


Is it worth mentioning that "classic" MacOS did not support ANSI, and that it was up to terminal authors to roll their own? And if that is worth mentioning, what about mentioning the Atari ST's use of VT52 codes instead of ANSI? If there are any GEMDOS users out there, was it also VT52 based? Maury Markowitz (talk) 22:05, 16 January 2015 (UTC)

I think not. Articles should be about their subjects. The subject here is ANSI escape codes, not all the terminal-ish things that didn't implement them. (I am about to remove the Windows NT command prompt window from the table of colors, on that basis.)
Discussion: However, perhaps it would be reasonable, given the chronology, to point out that a few prominent micros of the era didn't implement ANSI escape codes even though they had been established in the hardware terminal industry for years prior.
Remember that ANSI escape codes (and all the manufacturer- and model-specific codes that preceded them are important on a terminal - or an actual terminal emulator program that's doing serial comms with a remote system - is that the thing that's sending you data has nothing it can do but send "in-band" characters to you. Your terminal emulator displays some of them as-is, and others it interprets as commands; metadata, if you will.
But a character mode window implemented by an OS does not necessarily have any such restriction. The OS is free to provide APIs that allow programs to do everything the ANSI codes allow for, and more, without the programmer needing to build ANSI escape sequences and include them in whatever they're putc'ing. This to me is a key difference. Just because a character mode window happens to implement one or a few ANSI escape codes doesn't make it a terminal emulator, and the fact that it doesn't implement most or any ANSI escape codes isn't particularly notable.
Jeh (talk) 22:26, 16 January 2015 (UTC)
I agree with your ideas. See what you think of the edits. Maury Markowitz (talk) 15:28, 17 January 2015 (UTC)

Hard to locate information about the general syntax of those escape codes.[edit]

Some might visit this page just to see how they can filter those codes out of a stream of characters. How many characters to skip? Is there an "end" tag? All that sort of information is - if at all - hard to find in the article. (talk) 01:03, 18 February 2015 (UTC)

illegal(sic) characters embedded in CSI sequence[edit]

Without some specific wording in ECMA-48 (which was not cited), this area is addressed in one of vttest's screens: no terminal which fails to accept controls embedded in a CSI sequence is VT100-compatible. Perhaps the readers would prefer discussing some other type of terminal, in which case a suitable citation also is needed. TEDickey (talk) 23:55, 20 July 2015 (UTC)

That section either needs a citation or to be removed, I agree. By the way, does "accept" mean executing the controls, or just continuing to treat them like any other character in a CSI sequence? PsyMar (talk) 17:33, 31 July 2015 (UTC)

In my comment, I referred to a screen in vttest which looks like this:

Test of cursor-control characters inside ESC sequences.
Below should be four identical lines:

A B C D E F G H I 


In readable form, the characters sent "inside ESC sequences" are backspace and carriage return:

\E[1;1HTest of cursor-control characters inside ESC sequences.\r\r
\nBelow should be four identical lines:\r\r
\nA B C D E F G H I\r\r
\nPush <RETURN>

ECMA-48 is pretty explicit that C0 and C1 controls do not use bit patterns which could be part of CSI sequences. In reading ECMA-48, I do not see any discussion of illegal sequences (if for example the presence of a C0 byte in the middle of a CSI sequence would break the interpretation of the CSI sequence). Given the long duration of the vttest feature (from the mid-1980s) confirming that the VT100 executes these C0 controls, it appears that the VT100 designers read the standards as allowing any of the categories of controls listed in ECMA-48 section 5.1 to be interpreted concurrently. (I recall that perhaps some implementation mishandles this test, but that is irrelevant to this topic). TEDickey (talk) 00:33, 2 August 2015 (UTC)