A terminal in Linux is the text-based input and output device through which a user interacts with a shell and command-line programs. It sends keystrokes to a program and displays the characters that program writes back. Today it is almost always a terminal emulator, a graphical application or remote session that imitates the hardware terminals of the 1970s and 1980s.
The terminal is not the shell. The terminal handles display and keyboard input, while the shell, such as Bash or Zsh, interprets commands. Between them sits the kernel’s terminal subsystem, which manages line editing, special keys and signals. Understanding these three layers explains many everyday behaviors, from Ctrl+C stopping a program to garbled screens after printing a binary file.
Terminal, shell and console distinguished
Several related words are often used interchangeably, but each names a different component. The table below separates them.
| Term | What it is | Example |
|---|---|---|
| Terminal | Device or program for text input and output | A terminal window on a desktop |
| Terminal emulator | Software that imitates a hardware terminal | GNOME Terminal, Konsole, xterm |
| Shell | Command interpreter running inside the terminal | Bash, Zsh, fish |
| TTY | Kernel terminal device and its historical name | /dev/tty1, /dev/pts/0 |
| Console | The system’s primary terminal, often the physical screen | Virtual consoles reached with Ctrl+Alt+F3 |
| Command line | The text interface as a whole | Typing commands at a prompt |
The name TTY comes from teletypewriters, the electromechanical printers that early Unix systems used as terminals. Video terminals such as the DEC VT100 replaced them, and their control conventions still define how modern emulators behave.
How a terminal emulator works in Linux
A terminal emulator does not talk to the shell directly. It asks the kernel for a pseudoterminal (PTY), a pair of connected endpoints. The emulator holds the master side, and the shell runs attached to the slave side, which appears as a device such as /dev/pts/3. Programs on the slave side behave exactly as if they were connected to a real hardware terminal.
Between the two sides, the kernel’s line discipline processes the data. In the default canonical mode, it buffers input until Enter is pressed and handles Backspace, so simple programs receive complete lines. It also converts special keys into signals for the foreground process group. Full-screen programs such as text editors switch to raw or non-canonical mode to receive every keystroke immediately.
| Key | Default action | Effect on the program |
|---|---|---|
| Ctrl+C | Sends SIGINT | Interrupts the foreground program |
| Ctrl+Z | Sends SIGTSTP | Suspends it so the shell can resume it later |
| Ctrl+\ | Sends SIGQUIT | Quits, possibly writing a core dump |
| Ctrl+D | End of input at the start of a line | Program reading input sees end of file |
| Ctrl+S and Ctrl+Q | Stop and resume output, if flow control is on | Display appears frozen until Ctrl+Q |
These settings can be inspected and changed with the stty command; stty -a lists the current modes and key bindings. When a terminal closes, the kernel sends SIGHUP to the session, which is why programs started from a terminal normally stop when the window is closed.
Escape sequences and terminal capabilities
Programs control colors, cursor position and screen clearing by writing escape sequences, short byte strings beginning with the Escape character. Most follow the ECMA-48 standard, commonly called ANSI escape codes, extended by the VT100 and xterm families. For example, a sequence can switch text to red, move the cursor to a given row and column or switch to an alternate screen buffer.
Because terminals differ, programs consult the TERM environment variable, such as xterm-256color, and the terminfo database, which describes the capabilities of each terminal type. A wrong TERM value leads to missing colors, broken line drawing or misbehaving keys, especially over SSH connections to older systems.
Types of terminals in practice
Linux users encounter several kinds of terminal, each suited to different situations.
| Kind | Typical use | Notable property |
|---|---|---|
| Virtual console | Recovery when the graphical session fails | Provided by the kernel, no desktop needed |
| Graphical terminal emulator | Daily desktop work | Tabs, scrollback, fonts, copy and paste |
| GPU-accelerated emulator | Heavy output and large screens | Faster rendering, examples include Alacritty and kitty |
| Remote terminal over SSH | Server administration | Pseudoterminal created on the remote host |
| Serial console | Network devices, headless servers, boot problems | Works before networking is available |
| Terminal multiplexer | Persistent and split sessions | tmux or screen keep programs running after disconnect |
A terminal multiplexer deserves special mention for server work. It runs as a separate process that owns its own pseudoterminals, so a long job started inside tmux survives a dropped SSH connection and can be reattached later.
Common problems and their causes
Most terminal problems come from mismatched state between the program and the terminal. Printing a binary file can send stray escape sequences that change the character set, leaving the screen unreadable; the reset command restores a sane state. A program that crashes in raw mode can leave the terminal without echo, which stty sane fixes.
- Frozen output is often flow control triggered by Ctrl+S; pressing Ctrl+Q resumes it.
- Jobs ending at logout are caused by SIGHUP; use a multiplexer,
nohupor a service manager instead. - Interactive tools failing over SSH usually lack a pseudoterminal;
ssh -trequests one. - Wrong colors or keys usually trace back to an incorrect TERM value or missing terminfo entry.
Put simply
A terminal is the text window where you type commands and read the replies. It is like a telephone line to the computer. The terminal carries what you type and shows what comes back.
The program that actually understands the commands is a separate piece called the shell. The terminal is the screen and keyboard; the shell is the listener. Keeping the two apart makes it easier to see why some problems are about display and others are about commands.
In practice
A system administrator connects over SSH to a database server to rebuild an index expected to take three hours. Instead of running the command directly, she starts a tmux session first, so the job does not depend on her laptop’s network connection.
Halfway through, her train enters a tunnel and the SSH connection drops. Without tmux, the closed terminal would have sent SIGHUP and stopped the rebuild. Instead, she reconnects ten minutes later, runs tmux attach and finds the job still running. When a log file she prints later turns the screen into unreadable symbols, she types reset and the terminal returns to normal without closing the session.