Talk:ANSI escape code

Untitled

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 192.94.73.35 (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 217.26.150.114 (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 Terminal.app: F13 ^[[25~ F14 ^[[26~ F15 ^[[28~

iTerm2.app: 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 111.223.237.154 (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

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

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 http://www.zuggsoft.com/zmud/mxp.htm, 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

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

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"

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

Title of this article should be "ANSI escape sequences" (with disambiguation pointing to it for "ANSI escape code"). There is only one ANSI escape code; what is described by this page is a sequence of ANSI codes, not the single ANSI code point (0x1C) for the code usually referred to as "ESC".

However, I don't know how to edit the page to correct the title. Tripodics (talk) 13:41, 28 July 2018 (UTC)

"Franktur vs Fractur"

Shouldn't Franktur be Fraktur? Wikipedia appears to have chosen the second for other articles.

208.252.219.2 (talk) 22:54, 3 March 2010 (UTC)

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

xterm-256colors

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] 74.85.42.110 (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 81.233.4.136 (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": http://www.itu.int/rec/T-REC-T.416-199303-I/en — Preceding unsigned comment added by 80.192.180.160 (talk) 03:15, 25 June 2013 (UTC)

A little chaotic

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... --89.13.133.69 (talk) 00:56, 26 March 2011 (UTC)

use of source known to be inaccurate

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...). vt100.net 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)

http://vt100.net/vt_history TEDickey (talk)

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

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 188.233.8.82 (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

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)

Incomplete?

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 137.78.180.35 (talk) 01:02, 29 October 2011 (UTC)

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

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 en.wikipedia.org/wiki/xterm -> References -> 2nd reference == http://invisible-island.net/xterm/xterm.faq.html. Quoting http://invisible-island.net/xterm/xterm.faq.html#how2_title `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 85.64.29.102 (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,"

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

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 128.255.162.247 (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

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. 93.97.16.78 (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 http://osdir.com/ml/internationalization.linux/1999-09/msg00070.html and http://www.mail-archive.com/linux-utf8@humbolt.nl.linux.org/msg00210.html 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)

Fraktur

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)

Order

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 77.191.221.163 (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)

Printers

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.

GENICOM ANSI

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)

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

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

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

The developer's documentation at http://www.mirc.com/colors.html 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. 75.173.74.69 (talk) 14:23, 23 December 2014 (UTC)

I concur with @75.173.74.69: 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, @75.173.74.69:, 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

←[1;31mDerp! 

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:

• http://www.mirc.com/rfc1459.html
• https://tools.ietf.org/html/rfc2812

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:

• http://en.wikichip.org/wiki/irc/colors
• http://irssi.org/documentation/formats
• https://wiki.ietfng.org/pub/IRCIE/Encoding
• http://www.ircbeginner.com/ircinfo/colors.html

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?

• forums.mirc.com/ubbthreads.php/topics/249923/Color_index_RGB_values_documen#Post249923 75.173.74.69 (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.

• https://tools.ietf.org/html/rfc854

http://www.mirc.com/register.html (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. ~ 75.173.74.69 (talk) 02:31, 24 December 2014 (UTC)

@75.173.74.69:: 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)

Type:

//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. 75.173.74.69 (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. 75.173.74.69 (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 75.173.74.69 (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. 75.173.74.69 (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)

MacOS

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.

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.79.220.111.150 (talk) 01:03, 18 February 2015 (UTC)

illegal(sic) characters embedded in CSI sequence

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
A B C D E F G H I
A B C D E F G H I
A B C D E F G H I 

Push <RETURN>

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
\n\r\r
\nA B C D E F G H I\r\r
\nA
\E[2\bCB
\E[2\bCC
\E[2\bCD
\E[2\bCE
\E[2\bCF
\E[2\bCG
\E[2\bCH
\E[2\bCI
\E[2\bC\r\r
\nA 
\E[\r2CB
\E[\r4CC
\E[\r6CD
\E[\r8CE
\E[\r10CF
\E[\r12CG
\E[\r14CH
\E[\r16CI\r\r
\n
\E[20lA 
\E[1^KAB 
\E[1^KAC 
\E[1^KAD 
\E[1^KAE 
\E[1^KAF 
\E[1^KAG 
\E[1^KAH 
\E[1^KAI 
\E[1^KA\r\r
\n\r\r
\nPush <RETURN>
\E[2J

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)

You can download a "real" VT100 from a repository on Github, it's an 8080 emulator and some custom code sufficient to run a real VT100 ROM. It does show that a real VT100 fails some of the more recent tests in vttest though. 2001:470:1F09:10D6:5E26:AFF:FE7D:2F72 (talk) 22:52, 12 December 2015 (UTC)

Notable Exception in Lead

I don't understand why lead would have a "notable exception" instead of a "notable example" in the lead. Imagine if the WP article on metals ended the lead with "A notable non-metal is Oxygen." KazDragon (talk) 13:47, 9 November 2015 (UTC)

The only device/software in common use today that accepts a text stream as input for display to a user as a scrolling output with the newest text at the end that does not interpret ANSI is the Windows console. This exception is 'notable' because it is important enough to discourage usage of these sequences, especially in the stdout of software.Spitzak (talk) 23:46, 10 November 2015 (UTC)

The XTerm 6x6x6 cube is NOT the "websafe" colours.

The conversion from 0-5 to 0-255 is done with this expression:

nr = nr ? nr * 40 + 55 : 0;

NOT this one

nr = nr * 51;

That makes the XTerm colours quite a bit brighter. 2001:470:1F09:10D6:5E26:AFF:FE7D:2F72 (talk) 22:01, 12 December 2015 (UTC)

What about terminals that are not XTerm? Like VT241? Or VT340? Or Windows console? Or PuTTY? Do any of the standards cover this? ECMA-48 says to look at T.416, but T.416 says only that it is "the index into the colour table given by the attribute “content colour table” applying to the object with which the content is associated". Which is really helpful. 82.13.91.100 (talk) 23:45, 22 March 2020 (UTC)

Use of terminology and acronyms

This article doesn't even introduce what "CSI" is. It just goes straight into using the acronym, without establishing any prior context. The whole article reads like a reference sheet for geeks, rather than a general article explaining the concepts.

Also, the term "ANSI code" should probably be avoided without further qualification. There are many standards specified by ANSI that are also some kind of "code". Context that may be implicit on some technical forums is not necessarily implicit to a general Wikipedia audience.

WP:SOFIXIT. Jeh (talk) 23:12, 22 June 2016 (UTC)

And please sign your talk page posts? Jeh (talk) 23:14, 22 June 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on ANSI escape code. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20120113230301/http://www.pestingers.net/Computer_history/Computers_79.htm to http://www.pestingers.net/Computer_history/Computers_79.htm
• Added archive https://web.archive.org/web/20060206022229/http://enterprise.aacc.cc.md.us/~rhs/ansi.html to http://vt100.net/docs/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:17, 24 June 2017 (UTC)

Complete mess

This page is worse than useless. Half the escape codes here aren't even defined by ANSI X3.64 or ECMA-48. The whole article is just a dumping ground of pure garbage.

But it would be useful to know which ones aren't in the standard(s). Can you tell us? --Wtshymanski (talk) 01:32, 27 October 2017 (UTC)

Clarification for sentence in 24-bit colour section sought

"Also note that many implementation that recognize ':' as the separator erroneously forget about the color space identifier parameter and hence shift the position of the remaining ones."

I do not see how the first part of the sentence supports the second; also, which implementations manifest this behaviour?

Remember that any omitted numeric parameter is to be assigned the value of 0 (zero) so a sequence beginning with a 38 or a 48 code may legitimately leave off trailing zero values. In hindsight this make it a bit easier to see why ':' is used to separate the values because then it is possible to unambiguously decode something like:

\033[3;38:2:255;48:4:0:0:0:255;9m

// Later edit: The above is in error, it should have been:

\033[3;38::2:255;48::4:0:0:0:255;9m SlySven (talk) 11:54, 27 October 2019 (UTC)

as Italic, Struckout, Red on a Black background. I also wonder how XTerm would decode such sequences if the colons were semicolons - or is it that none of the parameter elements can be omitted in that case? Is that how it done Mr Tedickey? I acknowledge you as the go-to guru in this subject area! 8-) SlySven (talk) 02:12, 21 February 2018 (UTC)

The error is that the programs just reused their semicolon code for colon, which makes the first number be the red, not the color space ID. As you note trailing arguments can be deleted, so there is no way to determine which arrangement the program intended.Spitzak (talk) 06:06, 21 February 2018 (UTC)

xterm's behavior is documented in XTerm Control Sequences (talk page comments are by the way not a reliable source) TEDickey (talk) 10:12, 21 February 2018 (UTC)

I think I have been one of those who erroneously forgot about the colour space identifier and shifted the positions of the remaining parameters, to quote the section from (page 41) of the ITU-T Rec. T. 416 (03/93) document:

A parameter substring for values 38 or 48 may be divided by one or more separators (03/10) into parameter elements, denoted as Pe. The format of such a parameter sub-string is indicated as:

Pe : P ...

Each parameter element consists of zero, one or more bit combinations from 03/00 to 03/09, representing the digits 0 to 9. An empty parameter element represents a default value for this parameter element. Empty parameter elements at the end of the parameter substring need not be included.

The first parameter element indicates a choice between:

0 implementation defined (only applicable for the character foreground colour)

1 transparent;

2 direct colour in RGB space;

3 direct colour in CMY space;

4 direct colour in CMYK space;

5 indexed colour.

If the first parameter has the value 0 or 1, there are no additional parameter elements.

If the first parameter element has the value 5, then there is a second parameter element specifying the index into the colour table given by the attribute “content colour table” applying to the object with which the content is associated.

If the first parameter element has the value 2, 3, or 4, the second parameter element specifies a colour space identifier referring to a colour space definition in the document profile.

If the first parameter element has the value 2, the parameter elements 3, 4, and 5, are three integers for red, green, and blue colour components. Parameter 6 has no meaning.

If the first parameter has the value 3, the parameter elements 3, 4, and 5 and three integers for cyan, magenta, and yellow colour components. Parameter 6 has no meaning.

If the first parameter has the value 4, the parameter elements 3, 4, 5, and 6, are four integers for cyan, magenta, yellow, and black colour components.

If the first parameter element has the value 2, 3, or 4, the parameter element 7 may be used to specify a tolerance value (an integer) and the parameter element 8 may be used to specify a colour space associated with the tolerance (0 for CIELUV, 1 for CIELAB).

NOTE 3 – The “colour space id” component will refer to the applicable colour space description in the document profile which may contain colour scaling data that describe the scale and offset to be applied to the specified colour components in the character content. Appropriate use of scaling and offsets may be required to map all colour values required into the integer encoding space provided. This may be particularly important if concatenated content requires the insertion of such SGR sequences by the content layout process.

At first glance it is easy to misread the above - I now know I did (particularly the line I have bolded) - and even with NOTE 3, I am no wiser as to what that parameter means ... SlySven (talk) 19:47, 4 October 2018 (UTC)

Wording clarification: display attributes

"The display attributes remain in effect until the next occurrence of SGR."

This wording suggests that display attributes are cleared upon the next occurrence of SGR. For example, consider the independent display attributes italic and underline. Does the sequence CSI 3 m XXX CSI 4 m YYY show YYY with both italic and underline? If each SGR resets all display attributes, then codes such as CSI 24 (underline off) are unnecessary. The article should clarify that individual attributes continue until they are explicitly cleared by another SGR.

I made an edit to this effect.

Jim Fehrle (talk) 00:06, 27 March 2018 (UTC)

That means that the effect remains in effect until a following command that relates to that feature comes along to change it - so in the example you give "YYY" will indeed be both italic and underlined. An occurrence of SGRm, being equivalent to SGR0m will reset those and all other features - so it might have been a typo in that quoted sentence! SlySven (talk) —Preceding undated comment added 00:52, 1 May 2018 (UTC)

Reasons why most terminal emulators and system consoles supported ANSI escape codes?

The "Platform support" section claims that

The widespread use of ANSI by bulletin boards and online services led to almost universal platform support by the mid 1980s, first by video terminals, and then by terminal emulators (such as many communication programs for the IBM PC, ZTerm on the "classic" Mac OS, and xterm, GNOME Terminal, Konsole, and others on X11 systems, and MacOS Terminal).

Perhaps the DOS/Windows and classic Mac terminal emulators supported ANSI escape sequences in order to support bulletin boards and online services, but is that the reason why terminal emulators for UN*Xes supported them, or was that more due to the popularity of VT100s as terminals for pre-workstation-era UN*X systems? I doubt the authors of SunWindows/SunView's terminal program and xterm were primarily concerned about use of UN*X workstations to access BBSes and other online services, and I really doubt the authors of the GNOME and KDE terminal emulators cared very much at all about that, given the time when those were written. Maybe the NeXTSTEP terminal emulator developers cared, so that the macOS Terminal program, a descendant of that emulator, inherited the NeXTSTEP program's ANSI code support, but I'm even skeptical of that. Guy Harris (talk) 03:59, 11 April 2018 (UTC)

I would agree with your assessment. The ones for X11 were written to display output from local programs designed to display on VT100s. The problem is that people keep mixing in all the terminal emulators for Linux into lists of programs that were written for home PC's at that time.Spitzak (talk) 18:20, 11 April 2018 (UTC)

So perhaps we should limit the "Platform support" section to describing what platform support exists on various platforms, and not bother with any historical information or speculation as to why various terminal emulators supported ANSI escape codes? Then we'd just have as subsections, in addition to the DOS/Windows subsection we already have:

• a subsection for Unix-like systems, mentioning both the X11-based and macOS emulators, as well as system consoles for various OSes;
• a subsection for the classic Mac OS (which might say that the platform itself had no support, unless Apple shipped some sort of terminal emulator, with the only support being in particular applications such as ZTerm);
• a section for AmigaOS;

and mention the lack of support on the Atari ST somewhere.

The bit about BBSes and other online services is already mentioned in the History section; maybe whatever stuff isn't already there should be moved there from "Platform support". Guy Harris (talk) 19:33, 11 April 2018 (UTC)

As far as I can tell, BBSes were important in keeping these supported on PC systems, due to terrible support by manufacturers of computers that produced a video signal directly (not just the IBM PC, but Apple and most CP/M machines with built-in video). I would agree that everything about what happened should be moved to the History section.

I am not sure if we really need giant lists. Virtually *every* terminal emulation and RS232 video terminal made since about 1980 supported these. The notable exceptions are self-contained PC systems, including the IBM PC, and the terminal emulator Microsoft provided with Windows.Spitzak (talk) 01:04, 12 April 2018 (UTC)

OK, I've done some work on the "Platform support" section, and copied some stuff to History; how's the current state of those sections? Guy Harris (talk) 01:36, 12 April 2018 (UTC)

LGTMSpitzak (talk) 17:50, 12 April 2018 (UTC)

Could Unix-like systems and software running on them *really* "almost always" assume ANSI escape codes were usable?

The article claims that

Unix-like operating systems almost always could assume they were using a terminal or emulator that supported these sequences

According to the vi article:

The original code for vi was written by Bill Joy in 1976, as the visual mode for a line editor called ex that Joy had written with Chuck Haley. Bill Joy's ex 1.1 was released as part of the first Berkeley Software Distribution (BSD) Unix release in March 1978.

According to the VT100 article:

The VT100 is a video terminal, introduced in August 1978 by Digital Equipment Corporation (DEC). It was one of the first terminals to support ANSI escape codes for cursor control and other tasks, and added a number of extended codes for special features like controlling the status lights on the keyboard. This led to rapid uptake of the ANSI standard, becoming the de facto standard for terminal emulators.

and according to this article:

The first popular video terminal to support these sequences was the Digital VT100, introduced in 1978.

March 1978 predates August 1978, so it would appear that programs using cursor-control sequences to implement a full-screen editor predate "the first popular video terminal to support [the ANSI escape] sequences".

There may have been a point in time at which ANSI terminals were sufficiently dominant that programs didn't need to use termcap or terminfo, or libraries such as curses/ncurses that used termcap or terminfo, and could just directly use ANSI escape sequences, but I suspect that point in time came significantly later than the point at which UN*Xes had a significant number of programs using cursor-positioning escape sequences. Guy Harris (talk) 19:06, 3 July 2018 (UTC)

Sure - that had have been in the 1990s when graphical workstations (with terminal emulators) were more prevalent than hardware video terminals. TEDickey (talk) 20:45, 3 July 2018 (UTC)

And that was probably significantly later than the point at which UN*Xes had a significant number of programs using cursor-positioning escape sequences, so "Unix-like operating systems almost always could assume they were using a terminal or emulator that supported these sequences" is ahistorical, and the first paragraph of ANSI escape code#Unix-like systems needs to be rewritten to reflect history. Guy Harris (talk) 20:55, 3 July 2018 (UTC)

By about 1984 every single terminal used by any modern Unix machine interpreted ANSI escape sequences. This caused lots of software to ignore termcap/curses, for instance the prompt examples in this article right here. The most popular Unix is Linux (or maybe OS/X) which way postdates this.Spitzak (talk) 22:04, 3 July 2018 (UTC)

References

That's not close to being factual, but simply repeating your opinion. Offhand, there's the Wyse50 and Wyse60, which were used well beyond "1984". TEDickey (talk) 01:22, 4 July 2018 (UTC)

SGR 21—`Bold off` not widely supported

A previous commit removed from the SGR table the mention that bold off was not widely supported—it seems to have caused a bug with curl on MacOS (https://github.com/curl/curl/issues/2736) and I find that with Xfce#Xfce_Terminal (which is a "debian terminal" and thereby refutes the commit message there at least in part) I see a double-underline, xterm an underline, which seems to point that it is not widely supported.

A source file from the venerable ncurses library mentiones 21 as a double-underline code in a comment and so I added it back—the ECMA-48 that the comment references does indicate "doubly underlined" for 21. Not sure about consensus on the "bold off not widely used" or even "double underline not widely used" so just left a few examples. Any thoughts? –ASiplas (talk) 21:17, 7 September 2018 (UTC)

Just re-checked on xfce-terminal: ｢printf 'a\e[1mb\e[21mc\e[0m\n'｣ shows b but neither a or c bold, c without underlining of any kind. It's been years since I checked coverage of ANSI codes among terminals, but xterm is the only one with such a behaviour I know. Everything else consistently makes \e[2Xm disable what \e[Xm enables (for X in 1..9). -KiloByte (talk) 21:40, 7 September 2018 (UTC)

So in what document, if any, is SGR 21 specified as meaning "bold off" rather than "double underline"? ECMA-48 4th edition (December 1986) and 5th edition (June 1991) both say it means "double underline". Guy Harris (talk) 22:00, 7 September 2018 (UTC)

Hmm well perhaps behavior depends on more than just using a certain terminal (e.g. xfce-term). I'm seeing abc on xfce4-terminal 0.8.7.4 (both 'b' and 'c' bold, and 'c ' double underlined). With this much variation perhaps it safer to leave both? The lack of uniformity caused problems for those people at curl (bug linked above) and perhaps they looked here as a reference and assumed would always set bold to off. I came here after finding my terminal left in double-underline mode after running curl—someone using MacOS filed a bug after bold mode was left on (see link above). –ASiplas (talk) 22:33, 7 September 2018 (UTC)

Linux "console_codes" manual page says

21      set normal intensity (ECMA-48 says "doubly underlined") 

The comment about ncurses is misleading: the library does not know about a particular SGR code. That is the database (and a comment based on ECMA-48, if you chose to read the text). Likewise, mentioning PuTTY is misleading: it allows the double-underline as a regular underline (likewise, reading the source-code would be helpful). The comment above about xterm seems to be incorrect as well (the documentation is a good starting point) TEDickey (talk) 22:28, 7 September 2018 (UTC)

Fixed comment thanks –ASiplas (talk) 22:33, 7 September 2018 (UTC)

Standard ECMA-48 (which I foolishly thought would not be free and so didn't even look for it) states in §8.3.117 on page 61 (1998 reprint PDF) states unequivocally that SGR 21 indicates "doubly underlined" so I would vote if nothing else that either both stay or the "double underline" stay. Going to add reference to ECMA standard. –ASiplas (talk) 22:43, 7 September 2018 (UTC)

I researched this a bit: turns out not a single historical terminal whose manuals I looked at (vt100, vt220, vt520, ...) had such a functionality. It appears that this was a wishlist item in xterm's documentation (and xterm doesn't even implement it to this day!), that got copied around. All remaining terminals instead had 2X disable whatever 0X enables (just like 3X are consistent with 4X, 9X with 10X, etc). Only in vte0.51.2 this got changed, someone also submitted a kernel patch. As that's a regression which breaks existing programs, I just filed a bug report on vte. The offending version is present in Debian unstable but not in Debian stretch. -KiloByte (talk) 00:02, 8 September 2018 (UTC)

xterm patch #305 in 2014 implemented SGR 21. Perhaps you have an older version than that TEDickey (talk) 00:16, 8 September 2018 (UTC)

It understands the code but shows it as single underline, even at max supported zoom (as of xterm=335-1). New vte does double. -KiloByte (talk) 13:15, 9 September 2018 (UTC)

The program draws two lines, and it's documented that way. Bear in mind that Wikipedia is not a reliable source of information TEDickey (talk) 14:30, 9 September 2018 (UTC)

So, as of 2020-03-22, which terminal emulators, if any, treat SGR 21 as "bold off" rather than "double underline on" (or as a no-op because they don't implement double underline) in the most recent version? Guy Harris (talk) 05:02, 23 March 2020 (UTC)

Linux's documentation still said that til recently, noting an update here (though it was silently changed a couple of years ago), and as we know, a reliable source overrides other considerations. The primary-source for this was changed in the interim TEDickey (talk) 08:15, 23 March 2020 (UTC)

"it follows xterm rather than common sense and consistency, being the only command 1..9 where N+20 doesn't undo what N did"? Could somebody please point that person at ECMA-48, Fifth Edition, and point them to page 61, so they know that's 1) following the ECMA standard, inconsistent and non-common-sensical though they may think it, and 2) N+20, for some values of N, undoes multiple flavors of whatever N does, e.g. SGR 22 undoes both SGR 1 (bold) and SGR 2 (faint).

SGR 21, however, may either add double-underlining (if supported) to the existing modes, or replace the existing modes with double-underlining, depending on the setting of the "GRAPHIC RENDITION COMBINATION MODE". I guess if 1) double-underlining isn't supported and is "implemented" without actually underlining and 2) the terminal or emulator is in REPLACING mode rather than CUMULATIVE mode, SGR 21 could cause text to be displayed in the same fashion that SGR 0 would, and one effect of that would be to turn off boldfacing. But that's not because the SGR code for bold is 1 and 20+1 therefore means "turn bold off". Guy Harris (talk) 21:34, 23 March 2020 (UTC)

xterm 351, GNOME Terminal 3.34.1 using VTE 0.58.1, and konsole 19.12.1 on Fedora 31 (KDE spin for konsole), and Terminal Version 2.10 (433) on macOS 10.15.3, all appear to support only the CUMULATIVE GRAPHIC RENDITION COMBINATION MODE, so SGR 1 followed by SGR 21 either produces bold double-underlined text (GNOME Terminal), bold single-underlined text (xterm and konsole), or bold text (Terminal), and SGR 1 followed by SGR 4 produces bold single-underlined text in all of them. (Unless <ESC> 21 l = RM 21 doesn't reset the GRAPHIC RENDITION COMBINATION MODE back to REPLACING.) Guy Harris (talk) 22:11, 23 March 2020 (UTC)

It's not clear who you're addressing. In any case, talk page comments are not a reliable source, and what is needed is a reliable source. TEDickey (talk) 22:33, 23 March 2020 (UTC)

"It's not clear who you're addressing." 1) The person who made this commit and 2) those curious about the behavior of SGR 21 in popular terminal emulators. "In any case, talk page comments are not a reliable source, and what is needed is a reliable source." So that would presumably mean 1) a table of the most common terminal emulators (and terminals if we still care about them) from a reliable source and 2) documentation for those terminal emulators (and terminals) indicating that they don't implement SGR 21 as "bold off". Guy Harris (talk) 22:53, 23 March 2020 (UTC)

yes... I don't know where you'll find that (aside from someone who may feel inspired by this page to construct a table — which usually ends up being less than useful) TEDickey (talk) 23:15, 23 March 2020 (UTC)

Fix ESC sequence

In section "Escape sequences" you can find "Sequences have different lengths. All sequences start with ESC (27 / hex 0x1B / octal 033), followed by a second byte in the range 0x40–0x5F (ASCII @A–Z[\]^_).[16]:5.3.a

First, ESC + followed byte is not different lengths. Second, it's not valid ESC sequence.

See yours ref 16 (ECMA-48):

4.2.48 Intermediate Byte

a) In an escape sequence, a bit combination that may occur between the control function ESCAPE (ESC) and the Final Byte.

b) In a control sequence, a bit combination that may occur between the control function CONTROL SEQUENCE INTRODUCER (CSI) and the Final Byte, or between a Parameter Byte and the Final Byte.

ESC sequence is defined in ECMA-35:

4.17 Intermediate Byte

A bit combination which may occur between that of the control character ESCAPE and the Final Byte in an escape sequence.

13.1. ... The first byte of an escape sequence shall be the bit combination representing the ESCAPE character and the last shall be known as the Final Byte. An escape sequence may also contain one or more bytes known as Intermediate bytes.

...

I suggest to add

then by any number of "intermediate bytes" in the range 0x20–0x2F (ASCII space and !"#$%&'()*+,-./),

to ESC definition, as is now in CSI definition.

31.179.146.6 (talk) 11:24, 11 October 2018 (UTC) : rysson (Robert Kalinowski)

31.179.146.6 (talk · contribs), feel free to boldly make this update. II | (t - c) 11:40, 26 November 2018 (UTC)

Should we drop the "too technical" warning?

Usually, ANSI escapes will be used by programmers. So, I don't think many people who AREN'T programmers will visit this page often. Therefore, I believe that the "too technical" warning should be dropped, as this page's audience should be mostly programmers who can understand this stuff. Nathan0kulzer (talk) 13:16, 26 August 2019 (UTC)

Unless whoever put it there can clearly indicate what sort of stuff is "too technical" and what audience they think is appropriate as the "minimally technically aware", I'd say "drop it". If the idea is "try to explain it to somebody who doesn't know what a 'bit' is", then the goal isn't "write it so that person can read the article and understand it without having to, for example, click on the link to bit and read it to understand what a 'bit' is", the goal is "add enough links so that the reader can learn enough to understand it. Guy Harris (talk) 18:54, 26 August 2019 (UTC)

Since no one weighed in to oppose it, I went ahead and removed the tag. To my mind, the introduction and 'History' section are at the right level for non-experts, while the other sections are naturally more technical in nature. -- Rublov (talk) 00:57, 29 October 2020 (UTC)

Open Document Architecture

Some sections of this article discuss Open Document Architecture. While the content is interesting, I really think it belongs in that article rather than this one. The fact is, ODA is basically a failed standard – it never received widespread market adoption. It is interesting to know that parts of it involved defining ECMA-48-style escape sequences, but really the details of that, if they belong anywhere in Wikipedia, belong in the ODA article not this one–it was never intended for terminal emulators to directly support ODA; the ODA document would be loaded by a word processor which might use ECMA-48 escape sequences for display if it was a non-GUI text editor, and which would convert the ODA escape sequences to printer language instructions for printing (the printer language might have been ECMA-48-based, it might have been something completely different like PostScript instead.) SJK (talk) 14:17, 4 April 2020 (UTC)

"Some" means "two short sentences plus a see also list at the end", and if there are terminals or terminal emulators that accept ODA-derived escape sequences, that part is relevant here. Guy Harris (talk) 19:13, 4 April 2020 (UTC)

Well, what terminals or terminal emulators support ODA-specific escape sequences? Many terminal emulators support SGR 38 and 48 which may be derived from ODA, but the versions actually implemented in terminal emulators are highly simplified from the ODA specification and not compatible with it (even if somewhat inspired by it.) The rest of the numerous ODA escape sequences I don't believe any terminal emulator has ever tried to implement (and why should they, it is a file format specification for word processing documents not a specification for a text terminal.) The article currently says things like "gives an alternative version that seems to be less supported"–does anyone support it? why would a terminal emulator support one random item pulled from a specification for a word processing file format? Or similarly the statement "note that many implementation that recognize ':' as the separator erroneously forget about the color space identifier parameter and hence shift the position of the remaining ones" – no terminal emulator is trying to implement T.416, nor should it – why should a terminal emulator implement largely failed standard for a word processing file format?? SJK (talk) 20:06, 4 April 2020 (UTC)

Nowhere does the article (or do I) talk about implementing the full T.416 standard, so the full standard is a red herring.

When the article mentions ODA, it talks only about 1) the 8-bit color escape sequences, where T.416 uses a colon rather than a semicolon as a separator, and 2) the 24-bit color escape sequences, where T.416 again uses a colon as a separator and has some additional parameters. A terminal can implement that without implementing the entire standard. (Note, BTW, that ECMA-48, 5th edition, says SGR codes 38 and 48 are, reserved for setting foreground and background colors, respectively, "as specified in ISO 8613-6 [CCITT Recommendation T.416]", which might have inspired some terminal or emulator developers to use them for that purpose.)

At this point, the right thing to do is probably to ask for citations on 1) "an alternative version that seems to be less supported", 2) "Note that this uses the otherwise reserved ':' character to separate the sub-options which may have been a source of confusion for real-world implementations.", and 3) "Also note that many implementation that recognize ':' as the separator erroneously forget about the color space identifier parameter and hence shift the position of the remaining ones.". If nobody can come up with a citation for terminals or emulators using the colon or implementing the additional parameters, we remove the stuff about it as lacking citations, otherwise we leave the T.416 stuff there solely to indicate why the terminals or emulators in question supported colons as separators. Guy Harris (talk) 20:28, 4 April 2020 (UTC)

I think the problem is, that the way it is worded, it isn't making clear the fact that terminal emulators aren't trying to implement ODA at all, just taking inspiration from one tiny feature of one of the ODA specs. I think if we word it in such a way to make that clear, I wouldn't have a problem with referencing ODA. SJK (talk) 22:43, 11 April 2020 (UTC)

Test with Gnome terminal shows that it accepts the "\033[38;5;Nm" and ""\033[38;2;R;G;Bm" syntaxs. It also accepts the exact same thing with colons replacing the semicolons. It does not like it if there is a mix of semicolon and colon. And it does not like the "color space" number or any other numbers added to the start or end of the rgb syntax, even if colons are used.Spitzak (talk) 21:01, 4 April 2020 (UTC)

PU2

PU2_(ANSI) is a Redir to this article - but no mention. --Itu (talk) 05:34, 26 May 2020 (UTC)

Perhaps, at one point, this article talked about PU1 and PU2, but it currently doesn't, so PU1 (ANSI) and PU2 (ANSI) shouldn't redirect to this article. I've changed them both to redirect to C0 and C1 control codes#C1 control codes for general use instead, as that section at least mentions the Private Use codes. Guy Harris (talk) 05:56, 26 May 2020 (UTC)

use of primary source for promotion

It's (often) okay to use a primary source for stating that something exists, but using a primary source to state that something was first done in a given venue isn't good practice TEDickey (talk) 23:25, 4 June 2020 (UTC)

These people came up with the idea of having this extension. When it comes to parts that a standard does not cover, it's not sufficient to just state what something does, but also state who is using it. --Artoria2e5 🌉 09:43, 5 June 2020 (UTC)

Sure - I took out the word "first", because it went beyond the facts, and was promotional. TEDickey (talk) 22:41, 5 June 2020 (UTC)

"PC colors" as as SCO "invention"

The given source doesn't support the statement. To do this, it would have to either (a) point out that it was done first in SCO (Xenix?) with a year of introduction, or (b) a knowledgeable third-party source which makes this statement. For instance, it wasn't a new feature in 1997 when it was added to xterm, nor was it new when incorporated into Linux console a few years before that. So a 2003 manual mentioning the feature doesn't support the term "invention" TEDickey (talk) 13:39, 13 June 2020 (UTC)

80/132 cols

I suggest to add ESC[?3h and ESC[?3l that perform this switch. pietro151.29.37.171 (talk) 11:57, 8 December 2020 (UTC)

Dubious examples? Don't think so

Dear authors

The sentence "So, for example, <esc>[4;2~ is Shift-End, <esc>[20~ is function key 9, <esc>[5C is Ctrl-Right" has been marked as dubious. However, given that the tables below that sentence are correct, I think the examples are valid:

Example 1: <esc>[4;2~: This matches the general pattern "<esc> '[' (<num>) (';'<num>) '~'" with the explanation "keycode sequence, <num> defaults to 1" given above. As is explained in the text "If the terminating character is '~', the first number must be present and is a keycode number, the second number is an optional modifier value.". Therefore "4" ist the keycode, which according to the "vt sequences" table blow is "<esc>[4~ - End" and ";2" is the modifier. The modifier "... defaults to 1, and after subtracting 1 is a bitmap of modifier keys being pressed: Meta-Ctrl-Alt-Shift.". So 2-1=1 and in the bit map "Meta-Ctrl-Alt-Shift" this selects "Shift"

Example 2: <esc>[20~ This is F9 as per the "vt sequences" table: "<esc>[20~ - F9"

Example 3: <esc>[5C In the paragraph above the examples it is explained "If the terminating character is a letter, the letter is the keycode value, and the optional number is the modifier value." So "C" is the terminating letter and the meaning of the keycode letter "C" is "<esc>[C - Right" as per the table "xterm sequences". And from the modifier 5 one has to subtract 1 to get the value for the bitmap of the modifier keyes. So 5-1=4 and 4 selects "Ctrl" in "Meta-Ctrl-Alt-Shift".

So I think the examples are correct (but it took me a while to understand them).

So why dubious? 89.206.112.15 (talk) 09:44, 22 March 2021 (UTC)

Incorrect information about Windows Console being replaced

The information about the "Windows Terminal" is incorrect. It says "Windows Terminal, introduced in 2019, supports the sequences by default. Microsoft has deprecated the classic Windows Console subsystem and APIs, and intends to replace them with Windows Terminal going forward". I find it very difficult to believe that the Window Console Subsystem and APIs would ever be deprecated so I read the reference to it very carefully and I could not find any reference to the statement. There was a link in the reference page https://docs.microsoft.com/en-us/windows/console/classic-vs-VT which addresses concerns about the classic Windows Console subsystem and APIs, in section "Future planning and pseudoconsole" on this page it say this:

There are no plans to remove the Windows console APIs from the platform.

On the contrary, the Windows Console host has provided the pseudoconsole technology to translate existing Windows command-line application calls into virtual terminal sequences and forward them to another hosting environment remotely or across platforms.

Impression from the reference is that when users run "Command" or "Powershell" the terminal window will be Windows Terminal, and programs run inside it can assume ANSI sequences work. It does seem sensible that the old API would be emulated in this. The API is not being depreciated. But the inability to print escape sequences *is* being depreciated.Spitzak (talk) 01:56, 5 August 2021 (UTC)

3.10 has been incomplete for months

3.10 contains multiple occurences of "(draft section)" and uses code blocks instead of tables.

197.185.106.15 (talk) 04:36, 13 September 2021 (UTC)

Add SGR terminal support information

I believe it would be benefitial to add a column per teminal emulator implementation to state SGR code support. Kaznovac (talk) 15:13, 2 January 2022 (UTC)

perhaps not: you'd need a reliable source, and it's fairly well known that coverage is haphazard (see xterm FAQ) TEDickey (talk) 15:17, 2 January 2022 (UTC)

CP/M section barely mentions ANSI codes

I think the CPM section under history could be substantially cut down. It barely mentions ANSI codes at all and wants to talk about CPM hardware terminals instead.

Maybe CPM had substantial use in the 80s with ANSI terminals, but you wouldn't know it from reading that section.

terminfo/termcap color-support vs slang

That sentence needs a rewrite (color support in terminfo predates slang by more than ten years). TEDickey (talk) 18:37, 5 November 2022 (UTC)

Color definitions?

Were the colors referenced by the ANSI colors defined? Were they given names? Referenced to some other ANSI, FED or MIL standard? 1.159.58.220 (talk) 23:21, 11 February 2023 (UTC)

There aren't any "ANSI colors". ANSI X3.64-1979 says

ISO 6429 contains the following parameter values for use with SGR (Select Graphic Rendition) which are not present in ANSI X3.64-1979.

...

30 Black display

31 Red display

32 Green display

33 Yellow display

34 Blue display

35 Magenta display

36 Cyan display

37 White display

38 (reserved for future standardization)

39 (reserved for future standardization)

40 Black background

41 Red background

42 Green background

43 Yellow background

44 Blue background

45 Magenta background

46 Cyan background

47 White background

So they're "ISO colors", and are just given names, with no reference to any other standard. Guy Harris (talk) 00:02, 12 February 2023 (UTC)

ECMA-48 (2nd edition) gives further information, and appears to be the first published standard with these codes TEDickey (talk) 01:03, 12 February 2023 (UTC)

X3.64-1979 says

ANSI X3.64-1979, and ECMA-48, Additional Controls for Character-Imaging I/O Devices, were developed in parallel, with close liason. ISO DP 6429, Aditional Control Functions for Character-Imaging Devices, was developed as a synthesis of X3.64 and ECMA-48. During this process, some control functions as well as additional selective parameters weere added. Except for point 1 below, X3.64 is a subset of ISO 6429. Although the two standards use different language, the intent is that the subset is technically identical. X3.64 was balloted and forwarded prior to the final resolution of ISO 6429 and does not incorporate the owkr[sic] of ISO/TC97/SC2 in completing ISO 6429. Revision of X3.64 will attempt to incorporate those elements and assumptions of X3.64.

with "point 1" being that

X3.64-1979 contains a parameter value for use with SM (Set Mode) and RM (Reset Mode) which is not present in ISO 6429. It is:

3/2 3/0 LNM Line Feed New Line Mode

ECMA-48, 1st edition, March 1976, isn't available online from ECMA.

ECMA-48, 2nd edition, August 1979 is available (in a very obviously manually-scanned form; perhaps nobody had a copy of the 1st edition to scan). It has the colors, as well as some font selection options, including Fraktur (presumably at least one German-speaking contributor was involved in the spec :-)). It doesn't indicate what changed between the 1st and 2nd editions. It does say:

After having issued its Standard ECMA-35 for the extension of the 7-bit coded character set, the coding committee TC 1 of ECMA set up a task group with a view to developing a set of additional control functions. This work was conducted in close co-operation with the coding committee X3L2 of ANSI. Intermediate results were periodically discussed at the meetings of ISO/TC97/SC2. The first edition of Standard ECMA-48 was issued in September 1976.

In ISO/TC97/SC2 a working party developed an ISO Draft Proposal based on ECMA-48 and on the contributions presented by the representatives of X3L2. Several versions were drafted, submitted to SC2 and up-dated according to the comments received. Finally, at its May 1978 meeting, SC2 adopted the final text which will be processed as a draft international standard and eventually issued as ISO 6429.

This 2nd edition of ECMA-48 is based on the text of DIS 6429 and is technically identical with it. It has been accepted as an ECMA Standard by the General Assembly of ECMA on June 21, 1979.

ECMA-48, 3rd edition, March 1984 doesn't have any historical notes. ECMA-48, 4th edition, December 1986, says:

In parallel with the work on Standards ECMA-6 for the 7-bit coded character set standard, ECMA-35 for code extension techniques and ECMA-43 for the rules and structure of 8-bit codes, TC1, the coding committee of ECMA, worked on the definition and the coding of control functions to be used with the various standards for coded graphic character sets produced by ECMA, viz.ECMA-94, ECMA-113, ECMA-114 and ECMA-118.

The first edition of this Standard ECMA-48 was published in 1976. A second and third edition were published in 1979 and 1984, respectively. The text was technically identical with that of ISO 6429. In the meantime a revision of the latter has been undertaken by ISO/TC97/SC2/WG-6.

The scope of the standard has been enlarged so as to comprise all possible control functions needed by very different applications and cods, including those specified in ECMA-6 and the shift functions of ECMA-35. SC2/WG-6 being responsible in ISO for the standardization of the definitions and coding of control functions numerous requests have been received for inclusion of control functions needed in specific applications. As a consequence the publication of the next edition of ISO 6429 is delayed, although a body of about 150 control functions is now stable and well defined.

The present 4th edition of ECMA-48 contains the definitions and coding of all control functions already agreed by SC2/WG-6. The purpose of this publication is to make them available to the information technology community at large so that their implementation facilitates data interchange.

and ECMA-48, 5th edition, June 1991 says:

As part of the work on coded character set standards, TC1, the coding committee of ECMA, worked on the definition and the coding of control functions to be used with the various standards for coded graphic character sets produced by ECMA, viz. ECMA-6, ECMA-94, ECMA-113, ECMA-114, ECMA-118, ECMA-121, ECMA-128, and ECMA-144.

The first edition of this Standard ECMA-48 was published in 1976. Further editions followed. The fourth edition, published in 1986 was adopted by ISO/IEC under the fast-track procedure as second edition of ISO 6429. It constitutes a repertoire of a large number of control functions the definitions and coded representations of which are thus standardized. For each application the required selection of control functions can be made from this repertoire.

This fifth edition of Standard ECMA-48 contains the control functions already standardized in the fourth edition and, in addition, new control functions needed for handling bi-directional texts, i.e. texts comprising parts written with a left-to-right script and parts written with a right-to-left script. ECMA Technical Report TR/53 gives further information and examples of handling such texts. The inclusion of these specialized control functions has required a corresponding adjustment of the definitions of some of the other control functions. Moreover, the concept of "device" had to be revised.

This fifth edition has been contributed to ISO/IEC for adoption under the fast-track procedure as third edition of ISO/IEC 6429.

As for ISO 6429, it appears that the first edition came out in 1983, the second edition came out in 1988, and the third edition, which is the current edition, came out in 1992, so ECMA-48, 2nd edition (1979), predates ISO 6429, 1st edition (1983), and X3.64 didn't have the colors and has never, as far as I know, been revised, so ECMA-48 was, indeed, the first published standard with the colors.

The impression I get from the history given in X3.64 and the ECMA standards is that:

• ANSI and ECMA worked together on their standards, and also participated in the ISO standard;
• ECMA put out updates to ECMA-48, incorporating various stuff that happened in the ISO process, in order to get that stuff out in a standard without having to wait for ISO's process to complete;
• ANSI may have decided "it's in ISO's hands now, that's how we'll participate" and not bothered to put out any updates.

So perhaps the colors first came up in ISO and were put into ECMA-48, 2nd edition prior to the first edition of ISO 6429 being published, or they were in ECMA-48, 1st edition and got picked up in ISO 6429 from that standard. Not having the first edition of ECMA-48, I don't know whether it has the colors or not. Guy Harris (talk) 06:16, 12 February 2023 (UTC)

LNM would be on page 42, but I don't see it there. The 3rd edition (page 44) says to see appendix E (which is missing). The 4th edition (page 64) says it is reserved, and (pages 84-85) marks LNM as to-be-removed, alluding to some implementations, etc. The 5th edition says that it was deprecated in the 4th edition (page 88). It's in xterm, for DEC-compatibility TEDickey (talk) 10:29, 12 February 2023 (UTC)

1

print(""" This line is normal \033[1mThis line is bold This line is also bold \033[31mthis line is red and bold This line is red and bold, too \033[0m This line is normal again """) 175.100.6.65 (talk) 03:05, 22 February 2023 (UTC)