Hacker Neue

Preferences
ChuckMcM parent
This is a great article, at some point it will be a story like how the rail spacing in England is a function of the ruts created by the Roman chariots (unclear if that is actually the case (see snopes etc)), Having written tty driver code for FiNE (Fine-is-not-EMACS) there was a lot stuff related to just how fast the terminal on the other end of the serial channel could do stuff. (we had tunables for insert line, scroll etc).
jrabone
Great article, and your point about tunables is spot on; in the guts of several curses implementations there's an evil little select() call which is trying to work out if you meant "cursor down 1 line" or the four seperate characters ESC, [, 1, A by doing millisecond-precise timings.

IMHO I think this all needs to be replaced with something sane. VT100 is obsolete, and we can now spare a few more BPS for a better terminal layer. Wasn't so long ago that if you left capslock on, something (getty?) on the Linux console would assume your terminal was one of those olde-worlde 6-bit ones, and stop using lowercase letters...

jlgreco
"in the guts of several curses implementations there's an evil little select() call which is trying to work out if you meant "cursor down 1 line" or the four seperate characters ESC, [, 1, A by doing millisecond-precise timings."

If anyone is curious how to do that (useful if you want your terminal application to handle escape key presses for example), this is the basics of it:

    tcgetattr(master_controlling_tty, &term_settings);
    cfmakeraw(&term_settings);  /* set raw mode */
    term_settings.c_cc[VMIN] = 1;  /* minimum of 1 character per read */
    term_settings.c_cc[VTIME] = 1; /* 1 decisecond timeout for read */

    tcsetattr(master_controlling_tty, TCSANOW, &term_settings); /* write changes back to the tty */
Then if a read on your tty only returns the escape character, you know it was the escape key and not arrow keys or whatever.. unless there is some decent lag.. ;)

It's fairly simple to do, but certainly hackish.

dllthomas
> IMHO I think this all needs to be replaced with something sane.

It seems that we're in the process of replacing it with web tech, which may or may not meet your definition of "something sane"...

cturner
Web isn't a replacement. It doesn't and won't ever have consistent keyboard handling across platforms and browser upgrades. As a result, it has evolved to being mouse-centric, and is inadequate for high-volume users.

There are many web systems being developed as business front-ends today that would suck less were they menu and form-driven terminal apps with a couple of web screens for reports. (or a websockets arrangement where the terminal could render certain things to an associated browser when appropriate)

Jamiecon
Where I work, our > 15 year old ticket retail system was developed on a platform called Dataflex [0], which provides a character mode user interface. We have since migrated the datastore from the embedded ISAM database to Postgres, and built eCommerce and other web applications around the original schema.

Our administrative and call centre staff continue to use the original character mode interface to interact with the data and do their daily work. The software works and we have no reason to redevelop it anyway, but seriously, you should see the speed with which experienced staff move around the system. Editors can input hundreds of events an hour and call centre staff are amazingly efficient - they can practically use the thing blindfold.

There's a lot to be said for consistent keyboard controls and a distraction free interface in the workplace. Line of business applications from the last couple of decades, mostly mouse driven, are often tragically inefficient.

[0] http://en.wikipedia.org/wiki/Dataflex

cturner
Thanks. I have had a similar experience: when I was a teenager I helped with stock-take at a warehouse - once a year, for several years. I saw ladies doing data entry to terminals that were hooked up to an application running from another city on an IBM System/36 mini. They'd get ahead of the screen refreshes, but the UART diligently remembered each keystroke, and they'd power through. When I started out in my career I forgot all of this. I had to convert an existing 4D application a business loved for a multi-user application. I built an intricate system that was web only, with some javascript caching, accessed over a latent connection. The staff had a horrible time with this for several years. It was ultimately abandoned, and they moved to a paper system. I was uncomfortable with the memory but the penny didn't drop until I got into roguelike development. Huge regret - I should have remembered my time in the warehouse. If I had my time again I'd design most of the interaction in a termal as described above. The web is a toy.
yourapostasy
Somewhat sadly, it doesn't look like businesses are commissioning such character terminal interfaces any longer. Certainly not in sufficient volumes to support the few boutique shops that published and maintained text window libraries that some developers would use to insulate themselves from the insanity of supporting multiple terminal types on different systems. As far as I can tell from some Google searches, Vermont Creative Software's Vermont Views and Oakland Group, Inc.'s C-Scape are both no longer sold or even have a web presence. If it is true both went out of business, it would be a pity that such codebases are languishing in bit rot hell and could possibly disappear from the historical record. There were and are no comparable open source text window libraries with the polish these products had.
3 More Comments →
dllthomas
For a long time, TTYs didn't have very consistent keyboard handling across platforms (the web today seems better standardized than the mess of terminals curses was developed to deal with). I certainly make no claim we are done replacing it, and I'm not at all certain I think it's a good idea, it just seems to be what is happening in a haphazard way.
rbanffy
The risk is replacing it with something more complicated.

There are a lot of complexities introduced by the need to handle situations we may never again encounter. The challenge is to make everything simpler, not only in lines of code, but in abstractions.

hollerith
Although Plan 9 has its problems and I am not advocating that it should become mainstream, it has achieved a few things and one of those things is to have demonstrated (by example) that most of the stuff in the OP can be tossed and replaced with simpler things. Plan 9 has seen enough general use (e.g., as the daily environment of a largish group at Bell Labs) over the last 20 years for use to confidently say that much.

There is a program (called IIRC vt100) on Plan 9 that is used to talk to TTYs and serial ports, but it is rarely used, and it is the only part of Plan 9 that incorporates TTY-related concepts. Nor are signals a part of Plan 9, having been replaced by something called notes, which are conceptually different and simpler in concept and implementation.

I remember delving into the documentation of the stty command on Linux a few times in the 1990s. How I wish I could have those hours back (so I could do something more fun or more productive with them).

gaius
Well, you are conflating a couple of things there, VT100 and TCP/IP. VT100s were designed to use LAT (http://en.wikipedia.org/wiki/Local_Area_Transport) which is very different, e.g. rather than each keypress being a packet roundtrip to the server, it was line-oriented.

This item has no comments currently.