Why not fix the tty interface? [LWN.net]

Why not fix the tty interface?

Posted Jul 30, 2009 22:10 UTC (Thu) by spitzak (guest, #4593)
Parent article: A tempest in a tty pot

Before there was GUI's, I remember the #1 question from people trying to program Unix was "how do I make a getch() function?"

And the answer was "do this insane set of ioctls". Followed by "oh and make damn sure your program can NEVER EVER crash, because you must undo this before exit or other programs will be screwed up.

This was obviously insanely wrong then, and it still is now.

With shells using readline-style libraries now, there are NO programs left that use the TTY in anything other than uncooked mode (programs like cat that are mostly used as destinations of pipes do not count!). It does seem like it is time to scrap this. This would also allow "pty" to be scrapped as well, because you could use plain old pipes for this.

There should be a trivial uncooked raw io interface that you open as "/dev/newtty" or whatever. The drivers should be about 10 lines long I think.

The old tty/pty interface should be a CUSE api of some sort that emulates it atop the new interface. And that can be vastly reduced. For instance we can scrap the entire key assignment thing, as nobody ever alters it, and finally (after almost 4 decades!) get both Backspace and Delete to work at the same time!

(Log in to post comments)

Why not fix the tty interface?

Posted Aug 6, 2009 15:27 UTC (Thu) by forthy (guest, #1525) [Link]

Yes, I remember that when I started writing a Forth on Unix nearly 20 years ago. The tty interface is broken. Fundamentally. It's not even fixable. Give me a proper tty interface instead, and dump the old one. Write a CUSE driver for legacy applications.

Points I have to complain:

Obtain cursor position - impossible when the user types in something at the same time, due to inherent race condition. The root cause of this problem is terminal emulation. Whoever wants terminal emulation should link to /lib/libvt100.so or whatever terminal he likes to have.
raw/cooked mode and modes that persist over application changes: This is insane. Give everybody raw terminal access by default and whoever wants it cooked should link to /lib/libkitchen.so.

The Forth terminal model (that's what I wanted to adapt to Unix, and still haven't found a way to do that stable and bug-free) is quite simple: You can type text (which can be completely uninterpreted plain characters), you can send a carriage return, clear the screen, position the cursor, query the cursor position, (even more advanced: also the size of the terminal; setting colors and styles would also be advanced), check if there's a keyboard event available, obtain one and dispatch what type of event that is (character, function key - note that the terminal event model makes the terminal side of the pty a symmetric task to writing the client side). This separates terminal data (text) from terminal metadata (formatting, cursor positions, colors), and therefore is sane interface design. Each of the functions does exactly one thing, and does it right. Writing a Forth terminal driver for raw hardware (or just GUI emulation) is a piece of cake. Writing it for Unix is a PITA. If it is more complicated to do it through the OS than without, there's something seriously wrong with the OS.

If you happen to have a real terminal (old greenish CRT attached to a RS232 cable), you have to translate the metadata into data, and adapt to the terminal emulation (vt100 or any other of 1000 terminal "standards"). This ought to be an intermediate layer, provided by the system, not by the application. In Unix, you can't position the cursor just by calling an ioctl(). You have to use termcaps to find out which arcane set of string will position the cursor for you, or use one or the other arcane library ([n]curses is arcane) to do it for you.