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!
snogglethorpe
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.
etc.
emmelaich
Although sigkill should've been named sigstop and sigstop should've been sigpause. Ah, hindsight is a wonderful thing.
jlgreco
Eh, do you stop your car at an intersection, or do you pause it?
zx2c4
The article makes an interesting point
"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."
Can anyone provide any more insight about this?
ChuckMcM
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.
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.
Zenst
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.
kps
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.
Zenst
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.
stox
The concept of a teletype predated ASCII by decades. I would not use this article for any historical references.
cientifico
How many times this article appear at the hacker new front page?
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.
derleth
> wrote a terminal which doesn't even support escape sequences for coloring
Color can be a powerful way to organize large amounts of information quickly. What's the Plan 9 way to do that?
cm3
I don't know enough about Plan 9 to answer that.
joedoe55555
Ok, so how do I build a teletype that I can connect via USB to my Mac? (And will vi work? :D)
johncoltrane
While not exactly a teletype, Justin Ouelette's VT220 is cool:
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.
I don't think it's implied anywhere that it's hard or novel. He simply is more connected than you, that's all.
derleth
On the hardware level, does the VT 220 connect via a standard nine-pin serial port?
kps
"standard nine-pin serial port"
Them's fightin' words, boy.
DEC had a DE9 serial port connector whose pinout is not the same as the later IBM PC DE9 serial ports.
jasomill
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
gaius
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.
kps
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.
jlgreco
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.
sharkweek
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...
jrockway
Did you read the article? It was about UNIX terminals, not about text telephones.
derleth
If you can tell me how to use /dev/ttyS0 to make a prank call, I'm all ears. ;)
jrockway
Simply use a serial cable to connect your computer to a prank-calling device. Done!
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!
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.
etc.
"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."
Can anyone provide any more insight about this?
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...
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:
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.
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.
[0] http://en.wikipedia.org/wiki/Dataflex
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).
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.
http://news.ycombinator.com/item?id=4062981
Color can be a powerful way to organize large amounts of information quickly. What's the Plan 9 way to do that?
http://jstn.cc/post/8692501831
http://jstn.cc/post/13476503553
http://jstn.cc/post/10831555077
http://www.fastcodesign.com/1665509/digital-archaeology-hack...
http://justinouellette.com/
I've done it with an ADM-3A from the 70s too, it's just. Not. That. Tough.
http://imgur.com/bRnST here's me, years back, hacking on a VT 220
Them's fightin' words, boy.
DEC had a DE9 serial port connector whose pinout is not the same as the later IBM PC DE9 serial ports.
There's lots of original documentation for DEC VT series terminals here[1].
[1] http://www.vt100.net/
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.