Can terminal windows be modernized?
February 7, 2008 8:03 AM Subscribe
Is there any way to move UNIX terminals on from VT100 emulation?
This may be a totally naive question, but why are all the terminal emulators on Linux, BSD, OS X, etc. all based on VT100 or VT200 emulation. It seems silly that we're chained to the capabilities of these old hardware terminals still.
Is it possible to write a terminal from scratch that can run a bash shell and all the regular UNIX utilities without doing any VT emulation?
This may be a totally naive question, but why are all the terminal emulators on Linux, BSD, OS X, etc. all based on VT100 or VT200 emulation. It seems silly that we're chained to the capabilities of these old hardware terminals still.
Is it possible to write a terminal from scratch that can run a bash shell and all the regular UNIX utilities without doing any VT emulation?
Well, there's always a terminal. The little window on your screen is a terminal.
There has to be a way for the screen to say "move cursor left one character, turn the foreground to red, and print 'x'", all using a stream of characters. The methods of encoding that information and decoding and acting upon that information is the terminal you speak of.
Now, there are only so many things that a text screen can do. You use about 10% of them, and all the fancy ones were added /long/ ago, in VT100, VT220, VT420, ANSI, xterm, linux, WY370, et c., et c. There's rarely a need to add a new one, so we're hardly "chained"; we have way more capability than we use as it is.
So, the literal answer to the first part is "yes, you don't need terminal emulation, and you can simulate that by setting TERM to 'dumb'". The answer that you're getting at, though, is "no, all the fancy stuff you do with Bash and stuff relies on control sequences that you need a terminal layer for."
posted by cmiller at 8:28 AM on February 7, 2008
There has to be a way for the screen to say "move cursor left one character, turn the foreground to red, and print 'x'", all using a stream of characters. The methods of encoding that information and decoding and acting upon that information is the terminal you speak of.
Now, there are only so many things that a text screen can do. You use about 10% of them, and all the fancy ones were added /long/ ago, in VT100, VT220, VT420, ANSI, xterm, linux, WY370, et c., et c. There's rarely a need to add a new one, so we're hardly "chained"; we have way more capability than we use as it is.
So, the literal answer to the first part is "yes, you don't need terminal emulation, and you can simulate that by setting TERM to 'dumb'". The answer that you're getting at, though, is "no, all the fancy stuff you do with Bash and stuff relies on control sequences that you need a terminal layer for."
posted by cmiller at 8:28 AM on February 7, 2008
Oh, sorry, I may have misunderstood. If you care about avoiding "VT~" emulation only, then yes, certainly you can. I doubt that all Linux, WY370, HPTERM, and others are derived from DEC's VT line.
posted by cmiller at 8:38 AM on February 7, 2008
posted by cmiller at 8:38 AM on February 7, 2008
Best answer: Terminals, in Unix, have a long and storied history. There have been many different flavors with many different capabilities. The terminal is probably the oldest and deepest part of Unix that's still left; that cruft is over thirty years old.
Fundamentally, a terminal takes input from the computer and displays it. It also sends your keystrokes back. That's all. This is a 'dumb' terminal; the really dumb ones can't even do things like backspacing. (this was true of the early line printer terminals, where everything was sent in one line when you hit enter, and then a whole line or lines were printed out in return.)
That was, however, rather boring and limited. It was particularly bad when trying to display a full screen. Every time something changed, the entire screen had to be redrawn, which was a LOT of bandwidth, and which rendered the screen unusable between refreshes.
So, different manufacturers came up with different ways to send control codes to move the cursor around and display text in different styles (boldface was common); later on, even color started to happen. Every manufacturer did it differently. Every new terminal had new abilities that prior ones didn't have. This resulted in a tremendous number of different standards, and programming every application to deal with every possible terminal rapidly became prohibitive.
This led to the creation of the termcap library, and later terminfo; these simply encapsulated the codes for different features. You told the system what terminal you had, generally at logon, and all termcap-aware applications would then know how to drive it properly by using the library. This made things much easier; suddenly it didn't matter much if you had a Wyse or a DEC or some weird offbrand. All you needed was a termcap or terminfo entry, and your terminal worked. Yay!
So, at this point, everything uses vt100 because it has to use SOMETHING, and vt100 offers most of the capabilities needed in a basic text terminal. The Linux standard is also used a lot; it's a compatible superset of vt100.
COULD you write a new terminal? Absolutely. Your terminal application can use any codes you like. Build a termcap or terminfo for it, and voila, it would work with anything you wanted. This would be a big waste of time, with no real benefit, since that problem has been solved a billion different ways already, but yes, you could do your own, and it would be easy to use. All Unix apps can talk to any terminal you like. You just have to tell them how.
Note, however, that they only understand a certain set of feature. Termcap and terminfo represent the maximum possible feature set. Anything that termcap and terminfo don't cover, you'd have to manually fix programs to support, which is, again. prohibitively difficult. You would, instead, want to update termcap and terminfo with new features, write a driver for your particular terminal, and then convince people to use those features.
Nobody would bother, though. There's something better than terminals: X Windows, which is a zillion times more capable. That's what xterm is for... it's a termcap/terminfo-compatible implementation that runs in a window on an X desktop.
That's why terminals have stalled; why bother adding new features in text mode when you can just do anything you want with graphics instead?
posted by Malor at 8:42 AM on February 7, 2008 [3 favorites]
Fundamentally, a terminal takes input from the computer and displays it. It also sends your keystrokes back. That's all. This is a 'dumb' terminal; the really dumb ones can't even do things like backspacing. (this was true of the early line printer terminals, where everything was sent in one line when you hit enter, and then a whole line or lines were printed out in return.)
That was, however, rather boring and limited. It was particularly bad when trying to display a full screen. Every time something changed, the entire screen had to be redrawn, which was a LOT of bandwidth, and which rendered the screen unusable between refreshes.
So, different manufacturers came up with different ways to send control codes to move the cursor around and display text in different styles (boldface was common); later on, even color started to happen. Every manufacturer did it differently. Every new terminal had new abilities that prior ones didn't have. This resulted in a tremendous number of different standards, and programming every application to deal with every possible terminal rapidly became prohibitive.
This led to the creation of the termcap library, and later terminfo; these simply encapsulated the codes for different features. You told the system what terminal you had, generally at logon, and all termcap-aware applications would then know how to drive it properly by using the library. This made things much easier; suddenly it didn't matter much if you had a Wyse or a DEC or some weird offbrand. All you needed was a termcap or terminfo entry, and your terminal worked. Yay!
So, at this point, everything uses vt100 because it has to use SOMETHING, and vt100 offers most of the capabilities needed in a basic text terminal. The Linux standard is also used a lot; it's a compatible superset of vt100.
COULD you write a new terminal? Absolutely. Your terminal application can use any codes you like. Build a termcap or terminfo for it, and voila, it would work with anything you wanted. This would be a big waste of time, with no real benefit, since that problem has been solved a billion different ways already, but yes, you could do your own, and it would be easy to use. All Unix apps can talk to any terminal you like. You just have to tell them how.
Note, however, that they only understand a certain set of feature. Termcap and terminfo represent the maximum possible feature set. Anything that termcap and terminfo don't cover, you'd have to manually fix programs to support, which is, again. prohibitively difficult. You would, instead, want to update termcap and terminfo with new features, write a driver for your particular terminal, and then convince people to use those features.
Nobody would bother, though. There's something better than terminals: X Windows, which is a zillion times more capable. That's what xterm is for... it's a termcap/terminfo-compatible implementation that runs in a window on an X desktop.
That's why terminals have stalled; why bother adding new features in text mode when you can just do anything you want with graphics instead?
posted by Malor at 8:42 AM on February 7, 2008 [3 favorites]
Those old hardware terminals were pretty powerful, and allowed for complex cursor movements and key mappings. Without knowing what limitations are particularly bugging you, it'll be hard to suggest anything.
If you're just wanting to modernize for the sake of "newer is better", it isn't worth the time. As cmiller said, they can already do way more than any of us need these days.
posted by grumpy at 8:48 AM on February 7, 2008
If you're just wanting to modernize for the sake of "newer is better", it isn't worth the time. As cmiller said, they can already do way more than any of us need these days.
posted by grumpy at 8:48 AM on February 7, 2008
Another fundamentally different way to do terminals is the IBM mainframe way, like the IBM 3270. You have a screen of data, all sent to your terminal at once. You can type in values in the various fields with simple format checks. Maybe a search query, maybe data-entry. While you're doing that, nothing is being sent to the mainframe, so it's speedy. When you have the full screen filled out, you press the function key for submit, and it sends all the data, and you get a full response screen back.
posted by smackfu at 9:41 AM on February 7, 2008
posted by smackfu at 9:41 AM on February 7, 2008
I'd sure like a newer alternative to vt100 that was simpler to emulate. I've yet to see a single vt100 emulator that gets every detail correct. I'm really tired of weird display bugs, typically bad interactions with GNU readline. Maybe the bug is in termcap, maybe it's in the emulator, but either way it's clear that vt100 is really complicated.
There was a 10-12 year old terminal emulator called "uw". One neat feature it had was you could compile your own terminal definitions to emulate. Sort of the inverse of termcap. I remember I ended up using an adm31 terminal because it seemed to work the best / simplest.
posted by Nelson at 9:55 AM on February 7, 2008
There was a 10-12 year old terminal emulator called "uw". One neat feature it had was you could compile your own terminal definitions to emulate. Sort of the inverse of termcap. I remember I ended up using an adm31 terminal because it seemed to work the best / simplest.
posted by Nelson at 9:55 AM on February 7, 2008
Oh, by the way, if you're just looking for cooler ways to program terminals, look into ncurses. It has many neat features.
As an aside, it appears that there have not, in fact, been a billion terminals in the last thirty years. The Debian 'ncurses-term' package lists just short of 2,500 separate terminfo files.
Nelson: one common cause of problems is resizing a terminal when a program is running. If the program is other than bash, usually the resize events don't get properly fed back into the environment, and the display will go wonky. If you always resize your xterms or other terminals when you're at the command prompt, that will reduce the problems to a minimum. I can't remember the last time I saw a display bug from any other cause.
posted by Malor at 10:02 AM on February 7, 2008
As an aside, it appears that there have not, in fact, been a billion terminals in the last thirty years. The Debian 'ncurses-term' package lists just short of 2,500 separate terminfo files.
Nelson: one common cause of problems is resizing a terminal when a program is running. If the program is other than bash, usually the resize events don't get properly fed back into the environment, and the display will go wonky. If you always resize your xterms or other terminals when you're at the command prompt, that will reduce the problems to a minimum. I can't remember the last time I saw a display bug from any other cause.
posted by Malor at 10:02 AM on February 7, 2008
smackfu: Another fundamentally different way to do terminals is the IBM mainframe way, like the IBM 3270. You have a screen of data, all sent to your terminal at once. You can type in values in the various fields with simple format checks. Maybe a search query, maybe data-entry. While you're doing that, nothing is being sent to the mainframe, so it's speedy. When you have the full screen filled out, you press the function key for submit, and it sends all the data, and you get a full response screen back.
The same idea was later adopted by another type of terminal called a web browser.
posted by tetranz at 10:54 AM on February 7, 2008 [1 favorite]
The same idea was later adopted by another type of terminal called a web browser.
posted by tetranz at 10:54 AM on February 7, 2008 [1 favorite]
For those that are bored and geeky, a read though /etc/termcap is kind of oddly fascinating. Even more so, that a look at the "magic" file (usually /usr/share/magic on linux boxes these days). Unix anthropology.
posted by alikins at 12:39 PM on February 7, 2008
posted by alikins at 12:39 PM on February 7, 2008
Response by poster: Okay, you've all convinced me that the terminal emulation wheel is not worth reinventing.
I live in xterm all day long, and quite happily. So there's nothing in particular that I would want to changed... just that I remember my brain exploding the first time I tried to read the xterm man page. It went something like this:
"Hmmm, how do I get a better font in xterm. Let's see: man xterm. Tektronix what? VT what? What is all this? Oh, my god that's a lot of command line switches. Isn't there just an .xtermrc?"
*BOOM* ... brains and skull everywhere.
Then I learned about .Xresources and I was happy. Anyway, thanks for filling me in on the history.
posted by dehowell at 2:30 PM on February 7, 2008
I live in xterm all day long, and quite happily. So there's nothing in particular that I would want to changed... just that I remember my brain exploding the first time I tried to read the xterm man page. It went something like this:
"Hmmm, how do I get a better font in xterm. Let's see: man xterm. Tektronix what? VT what? What is all this? Oh, my god that's a lot of command line switches. Isn't there just an .xtermrc?"
*BOOM* ... brains and skull everywhere.
Then I learned about .Xresources and I was happy. Anyway, thanks for filling me in on the history.
posted by dehowell at 2:30 PM on February 7, 2008
Sure thing... remember there are other replacements, too. I quite liked Konsole when I last looked at it -- it's a KDE terminal application.
posted by Malor at 4:31 PM on February 7, 2008
posted by Malor at 4:31 PM on February 7, 2008
Tektronix terminals are (were) pretty cool, they can do vector graphics. gnuplot can still drive them. In xterm, ctrl-middle click and choose "switch to tek mode". A new window will open. Start gnuplot and do something like:
posted by reynaert at 5:10 PM on February 7, 2008 [2 favorites]
set terminal tek40xx
plot sin(x)posted by reynaert at 5:10 PM on February 7, 2008 [2 favorites]
This may be apropos or not, but the Hotwire shell is trying to blend a traditional shell with object-orientation and a modern GUI.
posted by Monochrome at 1:04 AM on February 9, 2008
posted by Monochrome at 1:04 AM on February 9, 2008
Response by poster: You know, I discovered Hotwire by coincidence Thursday night. It is REALLY cool. I tried using it exclusively at work yesterday (you can have a classic xterm in a tab as well), but it's a little slow to start.
I've got "open a terminal window" bound to alt-return, so I have developed pretty habit of:
open xterm
type three commands
close xterm
I do that dozens of times a day, and hotwire takes forever to open. But it is cool.
posted by dehowell at 5:33 AM on February 9, 2008
I've got "open a terminal window" bound to alt-return, so I have developed pretty habit of:
open xterm
type three commands
close xterm
I do that dozens of times a day, and hotwire takes forever to open. But it is cool.
posted by dehowell at 5:33 AM on February 9, 2008
Allow me to recommend rxvt-unicode as an alternative to xterm. Reasonably lightweight, but still supporting xft fonts. (But obscure enough that I have to install the terminfo locally on a lot of machines I talk to through it.)
posted by Zed_Lopez at 3:34 PM on February 11, 2008
posted by Zed_Lopez at 3:34 PM on February 11, 2008
This thread is closed to new comments.
posted by nomisxid at 8:27 AM on February 7, 2008