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 */
It's fairly simple to do, but certainly hackish.
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"...
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)
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.
Something that would be useful but which I don't think exists at the moment is a multiplexor. Like GNU/screen, but properly sandboxed. When the user logs in they get a menu program running on "tab 0". This program would spawn perspectives on new tabs.
Actually, maybe these things have features that I wouldn't know of being only a curses person. I'd be interested to know more if you wrote up a blog post. Email cratuki at the google mail server.
More elaborate libraries let you overlap the windows and would optimally redraw them when you moved the windows. They simply let you avoid having to roll your own text user interface starting from curses and building from there. Open source equivalents never approached the comprehensiveness or polish of these commercial libraries, though the open source ones are pretty good. Now that the commercial libraries appear to have dropped off the face of the earth, the open source ones seem to be all that is left. CDK [1] and NDK++ [2] on Unix and DFLAT [3] on DOS are examples of the open source libraries. I just felt the commercial libraries were interesting pieces of software history that should be preserved.
I personally feel that the kind of high-speed manual data entry optimization that these libraries facilitated is likely on its way out with advances in machine learning and the self-service customer culture of ecommerce. Certainly nothing prevents someone from using a standard web browser to present a user interface that responds entirely from keypresses, should the need for a highly optimized data entry-oriented Javascript library become necessary (something I've looked for but haven't found either for sale or open source). You would need to come up with a way to buffer up all the keypresses locally on the browser and ensure they all make it to the server, but it's doable.
If someone really had a burning desire to have some kind of in-house application presented through a character terminal interface via PuTTY in today's world, then they can still fall back to curses I suppose. Though I sometimes wonder if it would be faster to just write something in Emacs Lisp and autostart that when the user logs in.
[1] http://invisible-island.net/cdk/cdk.html
[2] http://ndk-xx.sourceforge.net/
[3] http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/deve...
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.
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).
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...