What I love is how they come up with different names for different signals that kill/suspend processes:
`SIGHUP`, `SIGINT`, `SIGQUIT`, `SIGABRT`, `SIGKILL`, `SIGTERM` and `SIGSTOP`!
7 different combinations of SIG and a verb that means "terminate/kill/stop/close/quit/suspend", and it's not that confusing (once you get your head around it). Must have been quite a challenge!
The names are not entirely arbitrary, though, and the nuances are actually meaningful, and based on real-world behavior.
E.g., "HUP" means hangup, and indeed, that's what you get when your modem hangs up accidentally! When handled by an application, it often is treated appropriately (e.g., the handler might trigger an autosave before quitting).
"INT" means "interrupt", and usage follows that sense -- it more likely than others to be ignored/repurposed (e.g. to quit back to some application prompt rather than killing the application entirely).
"ABRT" means "abort", and is typically used as a last-ditch means of killing the program when an internal error is detected.
"KILL" is more draconian than any other; there is no recovery possible.
"There's an important difference here: Writing to a TTY which is stopped due to flow control, or due to lack of kernel buffer space, will block your process, whereas writing to a TTY from a background job will cause a SIGTTOU to suspend the entire process group. I don't know why the designers of UNIX had to go all the way to invent SIGTTOU and SIGTTIN instead of relying on blocking I/O, but my best guess is that the TTY driver, being in charge of job control, was designed to monitor and manipulate whole jobs; never the individual processes within them."
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).
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...
"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.. ;)
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)
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.
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.
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.
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.
I'm prone to Yegge-length expositions in a blog, so the HN format might be better. These libraries could be thought of kind of like extensions to curses. In some cases, they actually depended on curses, in others, they did the work curses did and then went beyond that. You could typically draw into a defined buffer that represented a window, then have that window blasted onto the terminal replete with the character ASCII art that decorated the window borders without having to work out the arithmetic drudgery to put the right spaces and characters to draw the borders.
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.
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.
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.
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).
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.
Nice read, the part at the end "Finally, stty sane will restore your TTY device configuration to something reasonable" Realy should be what you learn from your fist instance of using a terminal (to many bad memorys of yesteryear systems over RS232 and uucp and modems, stop me now).
But everybody learns what they need to learn, even if it is setting the backspace/del keys to something visualy complient.
Knowing a tty and VT commands you can do some realy simple clever stuff, like find certain people logged in and there tty and cat append information to there screens and if they have terminals with extra sub lines you can sends a string that will memorise the screen cursor position, reposition cursor to the lower lines and display your text and then restore the cursor position. A very easy and simple way to instantly alert logged on users in certain groups. Can do all that in shell script easily. So knowing how things work and there capabilities and even there history and background so you understand why they are the way they are and from that appreciete there limitations. Then you can start doing some realy fun things. Again, nice read as verifys what you know and will fill in some worthy blanks.
Often when TTY settings are messed up by a full-screen program, you need to type «Control-J stty sane Control-J». It's necessary to use Control-J (i.e. newline) explicitly instead of pressing Return or Enter, because those generally send CR (Carriage Return, Control-M) and CR-to-newline translation is off.
Very true I instinctly do a ctrl-c first, but once you learn to not cat binary's/unsanatised data to your terminal you learn to add strings or use OD instead.
This shows why Plan 9 as part of the plan to fix inconsistencies and problems in UNIX wrote a terminal which doesn't even support escape sequences for coloring. I'm not a Plan 9 expert but it's actually for the better. Try launching some program like the sudoku game or acme from 9term inside Plan 9 compared to doing the same in plan9port's 9term or a plain xterm. On Plan 9 your 9term will become the program you launch.
What's most amazing to me is that this got so much press. Maybe OS X is ridiculously hard to set up, but I've been doing this on and off with my own VT 220 for the last 5 years on Linux. It's just... not that big of a deal. It's not archaeology, it's just pointing getty at /dev/ttyS0.
I've done it with an ADM-3A from the 70s too, it's just. Not. That. Tough.
IIRC, while the VT-220 had both 9-pin and 25-pin RS-232 ports, the 9-pin port was used to attach a printer. You also typically need a "null modem" adapter or cable to connect a terminal directly to a PC serial port (or USB serial adapter).
There's lots of original documentation for DEC VT series terminals here[1].
It has a 25-pin serial port which converts to a 9-pin serial port by a simple passive converter (basically, just ditch 16 of the pins and route the others properly, you can actually do serial with just two wires). Same goes for the ADM-3a
Huh, I was using a Wyse terminal on OSX years ago, right now tho' I am using an Atari ST as a terminal (and for 68k dev). Only a hipster would make a big deal about it.
You're better off finding an existing ASCII teletype. Then all you need is a USB-to-RS232 interface (FTDI and PL2303 ones work on OS X) and, depending on the machine, an RS232 to 20ma current loop interface, or a modem. Then simply edit /etc/ttys to enable getty on the appropriate interface.
Original vi has what is called 'open mode', which is effectively a one-line window intended for printing terminals. Neither nvi nor vim provide this, but line mode (ex) is more efficient anyway.
Hmm. Imagine a "teletype" jury-rigged out of a state of the art laser printer with Vim running on it. You would just have to position yourself or the printer so that every time the screen updated the next sheet of paper would land somewhere convenient.
Fascinating read -- when I was a bit... less mature, I used to use this service for many a prank call, which at one point apparently accounted for 85-90% of the calls according to some operators: http://en.wikipedia.org/wiki/Telecommunications_relay_servic...
