114 Terminal Insanity For many years programs kludged around the lack of a graphical API, hard-wiring into themselves the escape sequences for the most popular terminals. Eventually, with the advent of vi, Bill Joy provided his own API based on a terminal descriptor file called termcap. This API had two fundamental flaws: 1. The format of the termcap file—the cursor movement commands included, those left out, and the techniques for representing complex escape sequences—was, and remains to this day, tailored to the idiosyncracies of vi. It doesn’t attempt to describe the different capabilities of terminals in general. Instead, only those portions that are relevant for vi are considered. Time has somewhat ameliorated this problem, but not enough to overcome initial design flaws. 2. The API engine, developed for vi, could not be used by other programmers in their own code. Thus, other programs could read the escape sequences stored in a termcap file but had to make their own sense of which sequences to send when to the terminal.1 As a result, Ken Arnold took it upon himself to write a library called curses to provide a general API for VDTs. This time, three problems arose. First, Ken inherited the vi brain damage when he decided to use the termcap file. Starting over, learning from the mistakes of history, would have been the right choice. Second, curses is not a very professional piece of code. Like most Unix tools, it believes in simplicity over robustness. Third, it’s just a library with no standing, just like /etc/termcap itself has no standing. Therefore, it’s not a portable solution. As a result of these problems, only part of the Unix community uses curses. And you can always tell a curses program from the rest: curses programs are the ones that have slow screen update and extraneous cursor movement, and eschew character attributes that could make the screen easier to understand. They use characters like “|” and “-” and “+” to draw lines, even on terminals that sport line-drawing character sets. In 1994, there is still no standard API for character-based VDTs. 1And if that wasn’t bad enough, AT&T developed its own, incompatible terminal capability representation system called terminfo.

The Magic of Curses 115 Senseless Separators The myopia surrounding terminal handling has an historical basis. It begins with the idea that the way to view a text file is to send its characters to the screen. (Such an attitude is commensurate with the “everything is a stream of bytes” Unix mantra.) But herein lies the rub, for doing so is an abstrac- tion violation. The logical structure of a text file is a collection of lines sep- arated by some line separator token. A program that understands this structure should be responsible for displaying the file. One can dispense with this display program by arranging the line separator to be characters that, when sent to the terminal, cause it perform a carriage return and a line feed. The road to Hell is paved with good intentions and with simple hacks such as this. Momentary convenience takes precedence over robustness and abstractness. Abstraction (an API) is important because it enables further extension of the system it is a clean base upon which to build. The newline as newline- plus-carriage-return is an example of how to prevent logical extension of the system. For example, those in the Unix community most afflicted with microcephaly are enamored with the hack of generating files containing escape sequences that, when piped to the terminal cause some form of ani- mation to appear. They gleefully mail these off to their friends instead of doing their homework. It’s a cute hack, but these files work only on one kind of terminal. Now imagine a world with an API for directing the termi- nal and the ability to embed these commands in files. Now those files can be used on any terminal. More importantly, this API forms a basis for expansion, for portable files, for a cottage industry. For example, add sound to the API, and the system can now boast being “multi-media.” Fundamentally, not only is an API needed, but it must either be in the ker- nel or be a standard dynamically linked library. Some part of the OS should track the terminal type and provide the necessary abstraction barrier. Some Unix zealots refuse to believe or understand this. They think that each pro- gram should send its own escape sequences to the terminal without requir- ing the overhead of an API. We have a proposal for these people. Let’s give them a system in which the disk is treated the same way the terminal is: without an API. Application programs get to send raw control com- mands to the disk. This way, when a program screws up, instead of the screen containing gibberish, the disks will contain gibberish. Also, pro- grams will be dependent on the particular disks installed on the system, working with some but not with others. Of course, such a proposal for controlling a hard disk is insanity. Every disk drive has its own characteristics: these differences are best handled in