A TTY is a terminal device in the kernel that connects a program’s standard input and output to a user, providing line editing, signal generation and job control between the keyboard and the running process. In Linux, the name comes from the teletypewriters of early Unix systems, and today it covers virtual consoles, serial lines and the pseudo-terminals used by terminal emulators and remote shells.
Every interactive shell session runs on a TTY. The device is the reason that Ctrl+C stops a program, that a password prompt hides typed characters and that a full-screen editor can redraw the window when it is resized.
How a TTY works in the Linux kernel
A TTY sits between a terminal side, which produces keystrokes and displays output, and a process side, usually a shell. In the middle runs the line discipline, a kernel layer that buffers input, interprets special characters and translates line endings. In Linux, the default discipline is called N_TTY.
In canonical mode, also called cooked mode, the line discipline collects a full line, handles Backspace and Ctrl+U locally and delivers the line to the program only when Enter is pressed. In raw or non-canonical mode, each byte reaches the program immediately, which editors, pagers and shells with their own line editing rely on.
The line discipline also turns certain keys into signals for the foreground process group. The table shows the most important default bindings, which can be inspected and changed with stty.
| Key | Setting name | Effect |
|---|---|---|
| Ctrl+C | intr | Sends SIGINT to the foreground job |
| Ctrl+Z | susp | Sends SIGTSTP and suspends the job |
| Ctrl+backslash | quit | Sends SIGQUIT, often with a core dump |
| Ctrl+D | eof | Signals end of input on an empty line |
| Ctrl+S and Ctrl+Q | stop and start | Pause and resume output flow |
Types of TTY devices
Linux exposes several families of terminal devices under the /dev directory. They share the same kernel interface but differ in what sits on the terminal side.
| Device | Path pattern | Terminal side | Typical use |
|---|---|---|---|
| Virtual console | /dev/tty1 to /dev/tty63 | Kernel console on the local screen | Text login, recovery, Ctrl+Alt+F keys |
| Serial terminal | /dev/ttyS0, /dev/ttyUSB0 | A UART or USB serial adapter | Server consoles, routers, embedded boards |
| Pseudo-terminal | /dev/pts/N | A program holding the master side | Terminal emulators, SSH, tmux |
| Controlling terminal alias | /dev/tty | The current process’s own terminal | Prompts that bypass redirection |
| System console | /dev/console | Where kernel messages go | Boot output and emergency shells |
A pseudo-terminal (PTY) is a pair of devices. A terminal emulator or the SSH server holds the master side and writes keystrokes into it, while the shell sees the slave side, /dev/pts/N, as an ordinary terminal. New pairs are created by opening /dev/ptmx, and the tty command prints which device the current shell uses.
TTY, terminal emulator, console and shell
In shell and terminal work, four terms are often mixed up although they name different layers. The TTY is the kernel device; the terminal emulator is the graphical program that draws characters; the console is the physical or primary terminal of the machine; and the shell, such as Bash or Zsh, is the program that reads commands from the TTY.
| Layer | Example | Responsibility |
|---|---|---|
| Terminal emulator | A graphical terminal window | Rendering text, fonts, colors, input events |
| TTY or PTY | /dev/pts/3 | Line discipline, signals, window size |
| Shell | Bash or Zsh | Parsing commands, starting processes, job control |
| Program | An editor or a build command | Reading input and writing output |
Programs detect a terminal with the isatty check. When standard output is a TTY, many tools enable colors, progress bars and paging; when output goes to a pipe or a file, they switch to plain, script-friendly output. This explains why the same command can behave differently in a terminal and in a script.
Sessions, job control and terminal settings
Each TTY can be the controlling terminal of one session. Inside that session, the shell places each pipeline in a process group and tells the TTY which group is in the foreground. Background jobs that try to read from the terminal receive SIGTTIN and stop, which keeps input from being stolen.
When the terminal disappears, for example when an SSH connection drops, the kernel sends SIGHUP to the session. Long-running work therefore needs nohup, a service manager or a terminal multiplexer such as tmux, which keeps its own PTY alive independently of the client connection.
Terminal parameters are stored in a termios structure. The stty -a command lists them, including the window size in rows and columns, the special characters and flags such as echo. Resizing a terminal window updates the size and sends SIGWINCH, so full-screen programs can redraw.
Common problems and pitfalls
Many confusing terminal problems are TTY state problems, not shell bugs. A program that crashes while the terminal is in raw mode leaves echo disabled, so typed text becomes invisible.
| Symptom | Likely cause | Fix |
|---|---|---|
| Typed text not shown | Echo left disabled by a crashed program | Run reset or stty sane |
| Garbled line drawing characters | Binary output switched character sets | Run reset |
| Terminal frozen | Ctrl+S paused output | Press Ctrl+Q |
| Remote program warns about no TTY | Command run over SSH without a PTY | Use ssh -t to force allocation |
| Job dies after logout | SIGHUP on session end | Use tmux, nohup or a service unit |
Containers raise a related issue. Running a container without TTY allocation makes interactive tools misbehave, while allocating one in automated pipelines can mix error output into standard output, so the flag should be chosen deliberately for each case.
Explained without jargon
Long ago, people talked to computers through electric typewriters wired to the machine. Today the typewriter is gone, but Linux still keeps a virtual version of that connection for every terminal window.
That connection is the TTY. It carries every key you press to the running program and brings its answers back to the screen. It also understands shortcuts, such as the key combination that stops a stuck program.
A typical use case
A system administrator manages a rack server whose network configuration was broken by a faulty update, so SSH no longer works. The server’s management controller offers a serial console redirected to /dev/ttyS0, configured at 115200 baud in the kernel command line.
The administrator connects to that serial line, logs in on the text console, repairs the network file and restarts the service. Later, when running a long database migration over SSH, the same administrator starts it inside tmux. When the laptop’s Wi-Fi drops, the migration keeps running on its own pseudo-terminal, and reconnecting shows the progress exactly where it was.