Talk:ANSI escape code
|This is the talk page for discussing improvements to the ANSI escape code article.|
|This article is of interest to the following WikiProjects:|
- 1 Untitled
- 2 ISO 6429
- 3 Display codes
- 4 The ANSI brown/orange/yellow color and IBM CGA hardware
- 5 Category: User Interface Techniques
- 6 "ANSI escape code" vs "ANSI escape sequence"
- 7 "Franktur vs Fractur"
- 8 xterm-256colors
- 9 A little chaotic
- 10 Standard library?
- 11 use of source known to be inaccurate
- 12 For two character sequences the second character is in the range ASCII 64 to 95 (@ to _)
- 13 Example of use in shell scripting
- 14 Incomplete?
- 15 What is a single-character CSI (155/0x9B/0233)?
- 16 sparked a variety of "clones,"
- 17 ls syntax
- 18 assertion about C1 controls in UTF-8
- 19 Fraktur
- 20 Order
- 21 Printers
- 22 24-bit colors (sic)
- 23 not ANSIS.SYS
- 24 Amiga versus ANSI versus DEC
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 220.127.116.11 (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?
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
- 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)
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)
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)
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.
- 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
- 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"
"Franktur vs Fractur"
Shouldn't Franktur be Fraktur? Wikipedia appears to have chosen the second for other articles.
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.   18.104.22.168 (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 22.214.171.124 (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)
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... --126.96.36.199 (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)
- 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)
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.8.131.52 (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)
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 184.108.40.206 (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 220.127.116.11 (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,"
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 18.104.22.168 (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. 22.214.171.124 (talk) 23:01, 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://firstname.lastname@example.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)
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.05:43, 14 May 2013 (UTC)
- Sigh :( But thanks for the reply anyway. 11:07, 14 May 2013 (UTC)
At least on Linux here it appears that the order does not matter; the terminal software (e. g. xterm) will pick out what is reasonable for an ANSI sequence. For example, printf "\033[07;35m" and printf "\033[035;7m" will produce the same result at least here. Though not necessarily everywhere, I'd assume. -andy 126.96.36.199 (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). 13:31, 19 August 2013 (UTC)
A number of printers have used the ANSI emulation over the years. With obvious differences between a video terminal and a printer, there are different commands and similar commands are implemented differently.
|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. GENICOM. GEK-00031B.
24-bit colors (sic)
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)