TELOPT NEGOTIATION ------------------------ CLIENT RESPONSE TinyFugue TTYPE WONT NAWS WILL ECHO DONT EOR DO Gmud All No IAC response Windows Telnet TTYPE WILL,term_type ECHO DO Linux Telnet TTYPE WILL,term_type ECHO DO EOR DONT SecureCRT TTYPE WILL,term_type ECHO DO EOR DONT GA Not recognized Putty TTYPE WILL,term_type NAWS WILL ECHO WILL SGA WILL,DO EOR DONT TSPEED WILL NEW_ENVIRON WILL VT100/ANSI Code Reference ------------------------- This is not anything that's NORMALLY useful, but may be for a select few, and a good reference point. -Cygnus It isn't actually, there is a very simple algorithm for parsing all ANSI codes (even the ones that you don't know and wont implement) and that algorithm is itself part of the standard (but no one actually reads the standard itself because it is expensive and you can't find it on a web page -- so much for such standards being useful to the public). This is the 7 bit ASCII version of the escape code template: Define the following sets of characters: ESC = decimal 27 only set_1 = decimal 32 to decimal 47 inclusive set_2 = decimal 48 to decimal 63 inclusive set_3 = decimal 64 to decimal 126 inclusive An ``escape sequence'' is defined as: ES = exactly one ESC followed by zero or more from set_1 (known as intermediates) followed by exactly one from either set_2 or set_3 (known as final) One special escape sequence is called ``control sequence introduction'' which is: CSI = exactly one ESC followed by exactly one '[' A ``control sequence'' is defined as: CS = exactly one CSI (i.e. ESC '[' ) followed by zero or more from set_2 (known as parameters) followed by zero or more from set_1 (known as intermediates) followed by exactly one from set_3 (known as final) As far as I know, ``zero or more'' has no upper limit on it so ensure that a nasty sender can't use a buffer overrun attack. In practice, very long sequences are most probably an error or an attack even though they are theoretically legal. Probably throwing away the overflow characters and keeping the final is a reasonable approximation to correct. Once you have that, you can parse ANSI codes. The only code that I know of that doesn't fit the above is the linux console code to change the VGA palette and that is a really oddball code (it may be fixed by now, I haven't checked lately). Anyway, any terminal that uses codes outside the above template is also breaking the standard so you really shouldn't support it. There is a mapping between some of the common two character ES codes and single characters from the range [128 to 255] (i.e. outside 7 bit ASCII) which can be used for lines that are 8 bit clean (most lines these days). In particular a single byte CSI is defined which is what the Amiga uses. Unfortunately I don't have the mapping of these codes. I suspect that they might also be incompatible with UNICODE whereas plain 7 bit ASCII is compatible. So now there is no excuse for having strange codes turn up mixed with your text, even if you don't know what a code does, you still know that it is a code and that it should not be printed. If one of the above sequences gets a character in the middle of it (eg linefeed) that does not fit into the above template then the sender has made an error and you can do whatever you like in response. Most of the DEC terminals handle errors by making a guess at what the sender probably intended and doing that (e.g. silently behave as if the linefeed was seen BEFORE the escape sequence and continue from there). Similarly, cursor movement that takes you beyond the limits of the screen is an error on the part of the sender and you may do what you like, however the sensible thing is to move to the edge of the screen which is probably what was intended. So now you have the code, actually figuring the meaning of the code is another story, but it isn't as difficult as you might think. Firstly, the ``intermediates'' are almost never used. You have to allow for them when parsing out the code but you can often ignore the meaning of them in most cases. The ``parameters'' are almost always numbers separated by ; (although the :<=>? are legal here, no one seems to use them in practice). If any parameter number is omitted, it is presumed to be a default value, if any parameter number is 0 it is also presumed to be a default value. You only ever have one ``final'' and that always determines which command gets executed so putting a switch statement on the final and writing a generic parameter parsing routine has most of your problems solved. ---------------------------------------------------------------------- And a different posting with some of the more usual codes: ---------------------------------------------------------------------- From dkoepke@ScalPifoArniMa.com Tue Aug 10 01:14:15 1999 Today, Rich Allen asked on : > Is there a standard that MUDs follow regarding the use of ANSI > escape sequences? No. Fortunately or unfortunately (I think the latter), there are very few, if any, set standards by which all muds subscribe. You can, however, abstract a few de facto standards. The following is what I recommend clients support. Entries marked with an asterisk ('*') are for the bare minimal implementation (i.e., these are widely used and should be supported): (CSI is Control Sequence Introducer, which is escape followed by '[') CPS Cursor Position Save (*) CSI 's' (or '\x1b' '7') Save the current cursor position. CPU Cursor Position Update/restore (*) CSI 'u' (or '\x1b' '8') Restore the saved cursor position. CUB Cursor Backward CSI [number] 'D' Moves the cursor backwards 'number' amount of times. If 'number' is omitted or is '0', move backwards once. The cursor cannot be moved past the left margin and does not wrap around. Thus, if we receive CSI '5' 'D' and are only three spaces from the left margin, we only move three spaces backwards. No characters are deleted. CUD Cursor Down CSI [number] 'B' Moves the cursor downwards 'number' amount of times without changing the column position. The cursor cannot be moved past the bottom of the screen and *DOES NOT* cause scrolling. If 'number' is omitted or is '0', move downwards once. CUF Cursor Forward CSI [number] 'C' Operates as does CUB, but moves the cursor forwards rather than backwards. CUP Cursor Position (*) CSI [ line ';' column ] 'H' Positions the cursor at the specified line and column. If either is omitted or zero, we move the cursor to first line/column of the display. The sequence CSI 'H' homes the cursor (first line and first column). The cursor cannot move beyond the bottom right of the screen/window (thus, only move it to the bottom-right). You should also interpret the sequence CSI [ line ';' column ] 'f' in exactly the same manner, since some muds use it. CUU Cursor Up CSI [number] 'A' Operates as does CUD, but moves the cursor up rather than down. DSR Device Status Report (Report Active Position) CSI '6' 'n' The "ANSI" emulator should respond with a sequence in the form of CSI [ line ';' column ] 'R'. The mud receiving the code should understand that if line or column is zero or absent, the default is the first line or column. If both parameters are zero or absent, the default is the home position. ED Erase Display (*) CSI [param] 'J' Erase some or all of the characters on the display (screen/window). If the parameter is omitted, we default to '0'. If the parameter is '0', we erase from the cursor to the bottom of the display. If the parameter is '1', we erase from top of the display to the cursor. '2' means erase the entire display. EL Erase Line (*) CSI [param] 'K' Erase some or all of the characters on the current line. If the parameter is omitted, we default to '0'. If the paramter is '0', we erase from the cursor to the end of the line; '1', we erase from the beggining of the line to the cursor; '2', we erase the entire line. SGR Select Graphical Rendition (*) CSI attrib0 ';' ... ';' attribN 'm' Changes the current textual color/attribute/etc. All characters following the SGR are rendered according to the selected graphic rendition until another SGR is received, which modifies the current rendition. The following attributes are for a minimum implementation: 0 - reset to defaults (**) [see below for defaults] 1 - increased intensity 5/6 - blink 22 - normal intensity (undoes 1) [default] 25 - steady (not blinking, undoes 5/6) [default] 30/40 - black foreground/background [default background] 31/41 - red foreground/background 32/42 - green foreground/background 33/43 - yellow foreground/background 34/44 - blue foreground/background 35/45 - magenta foreground/background 36/46 - cyan foreground/background 37/47 - white foreground/background [default foreground] However, there are a lot of other codes for SGR that could be used to good effect if clients and servers supported them: 2 - decreased intensity or second color 3 - italicized 4 - singly underlined 5 - slowly blinking (less than 150/min) 6 - rapidly blinking (150/min or more) 7 - negative image 9 - strike-out 10 - primary font [default] 11 - first alternate font 12-19 - Nth alternate font 21 - doubly underlined 23 - not italicized (turns off 3) [default] 24 - not underlined (turns off 4 and 21) [default] 27 - positive image (turns off 7) [default] 39/49 - default foreground/background (**) [default] 52 - encircled 53 - overlined 54 - not encircled (turns off 52) [default] 55 - not overlined (turns off 53) [default] ** Implementation-defined (i.e., systemic or your own, if you're parsing them) Despite the verbosity of this, it is, by no means, a complete listing of all the attributes specified for SGR by the latest ISO 6429 (ECMA-048) standard, which replaced the outdated ANSI X3.64 standard. There may be others worth supporting, particularly FNT if we have support for SGR's 10-19 codes for font selection. > ANSI escape sequences are a bugger to pick out of text, Not really. The CSI ones end with a letter; the only others we need to bother with (the old way of save/restore) are '\x1b' '7' and '\x1b' '8', which shouldn't be hard to pick up. -dak : Remove the S...P...A...M... ---------------------------------------------------------------------- If you want to go further, find your local technical library (like at a university or technical college) and look for ANSI X3.41-1974, ANSI X3.64-1979 or whatever came later than those. Also look at old Amiga technical reference material (the Ami console was pretty close to ANSI) and old DEC VTxxx user guides (good luck) maybe even old MS-DOS manuals (I think they took the trouble to write documentation once upon a time before they realised how stupid their target market really was) because MS-DOS had an ansi.sys driver that contained all those codes. The ncurses distribution from GNU mirrors contains a big termcap file patched together from numerous sources containing incomplete control codes for bucketloads of terminals (but enough to get ncurses working on them all). You have to know how to read this file. The file /usr/src/linux/drivers/char/console.c contains C-code for an almost ANSI compliant terminal with most things you are likely to need. You do have that file I hope? You are writing under GPL I hope? Yet another option is to look at RIP codes which were an old BBS thing that was actually considerably more advanced than vt100 codes and very well documented at one time but then never took off If you want to use all of the above references and notice that they all conflict with each other -- welcome to the world of standards! - Tel