# Terminal, shell, TTY and console explainer

> Paste what `tty` printed — /dev/pts/3, /dev/tty2, /dev/ttyS0, /dev/tty, /dev/console, or “not a tty” — and see which layer you are actually looking at, what is holding the other end, and what that implies for signals, job control and what happens when the window closes. Local and offline.

- Tool: https://ronutz.com/en/tools/terminal-stack-explainer
- Family: Operations & Fieldcraft

---

## What it does

Run `tty` in a shell, paste what it printed, and the tool tells you which layer of the terminal stack you are actually looking at: a pseudoterminal slave, a virtual console, a real serial line, the controlling-terminal synonym, or the system console. It also handles **"not a tty"**, which is a finding rather than an error.

The four one-line definitions are shown **before** you paste anything, because a reader who arrives confused about the words should not have to supply input before the page tells them something.

## What each answer gives you

- **`/dev/pts/N`** — a pseudoterminal slave. Something in userspace holds the master: your emulator, `sshd`, or `tmux`. **The number is allocated, not meaningful** — two shells with consecutive numbers are unrelated. This is also why closing a window kills what was running: the master goes, the kernel hangs up, the session leader gets SIGHUP.
- **`/dev/ttyN`** — a virtual console, the kernel driving the machine's own keyboard and screen. Survives what a pseudoterminal does not, which is why it is where you end up when the display server has died.
- **`/dev/ttyS0`, `/dev/ttyUSB0`** — a real serial line, the original case unchanged. The tool warns that **serial parameters are not negotiated**: a mismatch produces convincing rubbish rather than silence, so a console showing garbage is usually a speed setting rather than a broken cable.
- **`/dev/tty`** — not a device but a **synonym** for whatever terminal controls the calling process. It explains why a password prompt still reaches you when output is redirected.
- **`/dev/console`** — where the kernel talks, and on a server frequently the serial port rather than the screen.

## What it will not do

It reads a path, not a system. It cannot tell you who holds the master for your particular `/dev/pts/3`, and it does not guess at unfamiliar device names — an unrecognised path is reported as unrecognised, because a platform-specific device should not be inferred from its spelling.

## Standards and references

- [Linus Akesson - The TTY demystified](https://www.linusakesson.net/programming/tty/)
- [IBM AIX documentation - tty special file and the controlling terminal](https://www.ibm.com/docs/tr/ssw_aix_71/filesreference/tty.html)
- [Unix & Linux Stack Exchange - What is the exact difference between a terminal, a shell, a tty and a console?](https://unix.stackexchange.com/questions/4126/what-is-the-exact-difference-between-a-terminal-a-shell-a-tty-and-a-con)

## Related reading

- [Terminal, shell, TTY, console](https://ronutz.com/en/learn/terminal-shell-tty-console.md): Four words used interchangeably by almost everyone, including the documentation. They name four different things, and the distinction explains why Ctrl+C kills your command but not your shell.