3

I have heard that VT100 is the de facto standard. Does it mean if I can just support VT100 and then my terminal can work for existing commandline applications without big problems? If not, how to make sure that terminal is practical? Is there any reference that can help to reach this goal?

V.D.D
  • 31
  • Tell us more about what you're trying to do. Are you writing it as a learning exercise? To do something that none of the available terminal emulators do? To be used in some non-standard environment? – JigglyNaga Jun 15 '16 at 08:20
  • Why implement a new terminal emulator. Join one of the existing open source emulator development efforts instead if you want to do something useful. – Anthon Jun 15 '16 at 08:28
  • @JigglyNaga Yeah, for learning exercise. I'm also thinking how to implement a shell in it. Suggestions are helpful to let me avoid implementing something not practical. – V.D.D Jun 15 '16 at 08:29
  • To me the question is quite legit. The motivation is clear, if you want to create a terminal emulator from scratch you just want it to be useful, modern, supporting most of software people will run inside of it. It is not really fair to mark it as "opinion based" although maybe the question could be rephrased to something like "how to write a terminal emulator from scratch to be compatible with most of the terminal-based software in use". – exebook Dec 28 '18 at 17:37

1 Answers1

13

You're about to get Thomas Dickey overheated.

Ignore the samizdat that has been circulating for years about VT10x terminals. Much of it is wrong. The DEC VT100, VT101, and VT102 implemented a very specific set of functions, which one can learn from reading their doco.

That is not what people who go incorrectly bandying around the terms vt100 and vt102 actually mean, however. Often, what they are talking about is a terminal emulation that does a whole lot more than what a real VT10x did, as well as a whole lot less. A real DEC VT102 had an attached serial printer, and control sequences for accessing it, for example. It furthermore did not have many of the control sequences from later terminal emulators and real terminals that people erroneously ascribe to "vt102". It had no concept of SGR colour changes, for example.

You have two basic choices:

  • Implement something that is compatible with an existing terminal type that is defined in the termcap/terminfo databases. If you do this, you must do it correctly, exactly copying all of the existing terminal type's described behaviour. (The nosh toolset's terminal emulator does this, emulating on Linux the linux terminal type. It has to copy the linux terminal type's quirky and limited extended key and function key encodings.)
  • Implement your own terminal type, whose behaviour is designed by you, which you then have to get included in the termcap/terminfo database. The PuTTY terminal emulator, strictly speaking, does this. The correct terminfo description for it is putty, putty-256color, or putty-sco.

For the former, what is standard is irrelevant, as you have to copy the described behaviour no matter how non-standard it may be. For the latter, do not look for de facto standards. Look at the actual standards, some of which have been around since 1976.

  • ECMA-48 (first published in 1976 and later adopted as an ISO/IEC standard, ISO/IEC 6429) describes:
    • C0 control codes,
    • C1 control codes (which are little known but deal in several useful things like setting/clearing tabstops and forward/reverse index)
    • 7-bit aliases for all C1 control codes (for example, ESC [ is a 7-bit alias for the actual 8-bit control character U+009B),
    • control sequences introduced by CSI (for which there is a general syntax in the standard that many samizdat-written control sequence parsers get wrong),
    • and a whole lot of other stuff.
  • ISO/IEC 2022 describes switching amongst 7-bit character sets. If you are going to implement UTF-8 capability from the start, ISO/IEC 2022 is best completely ignored, as Markus Kuhn and the inventors of mosh will tell you.
  • ISO/IEC 8613-6 (published in 1989 and revised in 1994) describes extensions to ECMA-48 for colour SGR control sequences, both "indexed colour" selection from a palette and "direct colour" RGB. (Both direct colour and indexed colour are defined in ISO/IEC 8613-2. You'll probably know the latter by the samizdat name of "256 colour".)

    Important note: Almost all implementations implement this standard wrongly, because they worked from samizdat (or simply copied one another) rather than from the actual standard. The standard says in §13.1.8 to use colon (:, "3/10") as a sub-parameter separator; almost all implementations erroneously use semi-colon (;), introducing a parsing ambiguity. A lot of softwares have accommodated this error.

Further reading

JdeBP
  • 68,745
  • So detailed! Before I decide whether to edit the question, I want to know how to make sure most commandline applications can run well in the terminal? – V.D.D Jun 15 '16 at 10:55
  • Especially, how can a custom terminal type like putty's work for the existing programs? – V.D.D Jun 16 '16 at 01:47
  • 2
    Most command-line applications that need advanced TTY control won't implement it on their own, but use a library to handle the actual control codes. Historically, this library was known by the name curses; the modern version is ncurses. These libraries use a terminal description that identifies all the features available in a particular terminal type. The terminal description comes either from the terminfo database (modern) or from the /etc/termcap file (classic). So if you implement a new terminal type, you should also write a description for it and install it to your system(s). – telcoM May 14 '18 at 06:33
  • ...and before anyone else comments on this: yes, the termcap vs. terminfo is actually yet another difference between the legacies of BSD vs. SystemV. – telcoM May 14 '18 at 06:42