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

116 Terminal Insanity one place, by a device driver. Not every program or programmer is letter- perfect: operations like reading or writing to the disk should be done only in one place within the operating system, where they can be written once, debugged, and left alone. Why should terminals be treated any differently? Forcing programmers to be aware of how their programs talk to terminals is medieval, to say the least. Johnny Zweig put it rather bluntly: Date: 2 May 90 17:23:34 GMT From: zweig@casca.cs.uiuc.edu (Johnny Zweig) Subject: /etc/termcap Newsgroups: alt.peeves2 In my opinion as a scientist as well as a software engineer, there is no reason in the world anyone should have to know /etc/termcap even EXISTS, let alone have to muck around with setting the right envi- ronment variables so that it is possible to vi a file. Some airhead has further messed up my life by seeing to it that most termcaps have the idea that “xterm” is an 80x65 line display. For those of us who use the X WINDOWS system to display WINDOWS on our worksta- tions, 80x65 makes as much sense as reclining bucket seats on a bicycle—they are too goddamn big to fit enough of them on the screen. This idiot should be killed twice. It seems like figuring out what the hell kind of terminal I am using is not as hard as, say, launching nuclear missiles to within 10 yards of their targets, landing men on the moon or, say, Tetris. Why the hell hasn’t this bull been straightened out after 30 goddamn years of sweat, blood, and tears on the part of people trying to write software that doesn’t give its users the heebie-jeebies? And the first person who says “all you have to do is type ‘eval resize’ ” gets a big sock in the nose for being a clueless geek who missed the point. This stuff ought to be handled 11 levels of software below the level at which a user types a command—the goddamned HARDWARE ought to be able to figure out what kind of terminal it is, and if it can’t it should put a message on my console saying, “You are using piss-poor hardware and are a loser give up and get a real job.” —Johnny Terminal 2Forwarded to UNIX-HATERS by Olin Siebert.