I am trying to understand Linux' terminal subsystem, especially the tty drivers and line discipline. Apparently, the architecture of this subsystem stems from a time where teletypewriters (ttys) were connected to a computer to input data into the computer and get a process' response.

I have never worked on a real historical tty and I believe that when I understand how such a tty worked I am better able to understand the intrinsics of a tty driver.

I am particularly interested in echoing and line editing.

So, when the operator on the tty would type the text: was the text echoed on the tty (by printing a line on the paper)? Is it echoed while he typed the individual keys/characters or only when he pressed the new line/enter key.

Are the keys (characters) that he types immediatly delivered to the computer (line discipline?) or are they stored in a buffer local to the tty and delivered when the new line key is pressed.

How did an operator edit wrong text (backspace, ctrl-h)? Would the backspace information be sent to the computer where the line would be accordingly edited or was that a feature of the tty (withcut the computer noticing it)?

And finally, what happened if the operator typed in text while the tty was receiving data from the computer?

2 Answers 2


The original ttys were like the ASR33 Teletype Model 33. They are "dumb" and when you press a key it sends a character to the modem or computer. The computer can then send back a character and it is printed.

This also provides feedback that the transmission worked. It also allows the computer to send back 2 or more characters when you only type 1. For example, you type enter, and it sends back both a carriage-return to move the print head to the left margin, and then a line-feed to move up the paper to the next line. This is why you still see today the option stty onlcr which means translate output newline to carriage-return newline.

It is also the reason for the option to have a delay after printing carriage-return (to allow the print head to move back).

You could have editors that would echo backspace with backspace, X, and forward-space, hence striking out the last character. If repeated the editor could backspace further to strike out more, and then put the print-head at the end again when you typed new characters.

When not in an editor, the line discipline keeps the current line typed so far (hence stty cooked mode), after the removal of characters from the end of the line with backspace. It provides stty rprnt to let you specify a character to type that will reprint the entire line so far, after the backspaces you typed have had their effect.


Features of tty devices aren't always dependent on the behavior of some dot matrix line printer that may or may not be attached. Keep in mind that tty's were also used by thin clients like DEC's VT220 which could have operated as a CRT attached to an external modem via parallel port, like a U.S. Robotics 9600 bps Courier model for example.

When you have such a small amount of bandwidth that you're dealing with (although 9600 bps was considered relatively "fast" at the time) and you're sending a file over a POTS modem, you don't want to have to upload the file twice by waiting for the remote system to echo everything back to you. Likewise, you don't want to waste CPU cycles on the remote system by waiting for it to write something back to you when you already know what it is.

It would have been the same idea when you're dealing with a telnet connection over the Internet. Telnet is not a raw TCP connection! It's an actual Internetwork specification (RFC854) with IAC ("Interpret As Command") protocol data that aids in controlling tty behavior. Programs that manipulate tty devices like setserial, getty, etc. utilize the ioctl ("I/O control") system call and the termios.h header file defines preprocessor constants to that end..

$ whatis ioctl tty_ioctl
ioctl (2)            - control device
tty_ioctl (4)        - ioctls for terminals and serial lines

Similarly, POTS modems utilized the Hayes "AT" command set for controlling local echo. Terminal emulator programs like minicom and others also have configuration settings for controlling terminal activity from their perspective. Therefore, tty settings need to be tweaked to operate in concert with all other technologies being used. For the same reasons, line editing was created to both save bandwidth and printer paper. Why send a line along to the other system for processing or to a printer to be inked onto paper when you're not even sure it's what you want?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .