What really happens inside a terminal

A terminal is just a channel for text: the keys you press go in, and a program's output comes back out. That's it. The word is older than screens — it comes from the teletype, a typewriter wired to a far-away computer. Today almost every terminal you use is faked in software: your SSH session, the terminal app on your laptop, a tmux window. They all pretend to be that old machine.

On a shared Linux server, several people can be connected at once. A single command — w — shows them all and what each is doing. Reading its output raises every question this guide answers: what is pts/0? Why does one session show -bash and another a running program? And could one user read what another is typing?

w shows who is logged in and what they're doing right now. Here's an example snapshot from a shared server. Tap any column heading (or a row) to see exactly what it means — the headings are the tricky part.

TTY stands for teletypewriter — those original wired typewriters. Today it just means “a terminal device,” and every terminal is a file under /dev. There are two broad kinds, and the names in w's TTY column tell you which is which.

A pty always comes as a pair. One side — the master — is held by the program that manages the terminal (sshd, your terminal app, screen). The other side — the slave, /dev/pts/N — is what your shell and programs talk to as if it were real hardware. The “s” in pts is that slave end.

Press a key below and follow one byte: input flows master → slave → shell; the shell's output flows back shell → slave → master → your screen. Same wire, both directions.

Try to cat a terminal and nothing appears — it just sits there. It looks like an empty file. It isn't. These aren't files with contents at all; they're character devices (the c at the start of crw--w----). cat doesn't read stored bytes — it opens the device and asks the kernel for live input. A terminal has no end-of-file, so cat blocks forever waiting for input that never comes. Not empty — a live stream with nothing flowing.

Here's the part that feels like magic. As root, cat /dev/pts/0 opens another user's terminal. But remember: a terminal's input is consumed, not broadcast — the kernel hands each typed character to exactly one reader. So when you attach your cat to a live session, every keystroke that user types is split between their shell and your cat, semi-randomly.

That means it's not a quiet wiretap. It steals input from the real user and garbles their session — characters vanish on them while fragments land in your cat. A clean command can arrive as gibberish, its characters scattered between the two readers. Run the demo and watch one command get torn in two.

When the kernel creates a pty it sets the owner to the session's user and a mode of roughly crw--w----. Decode it: owner gets rw-, group (tty) gets -w- (write only — that's for wall/write messaging, not reading), and everyone else gets --- (nothing). So a normal “other” user simply can't open it to read. Flip the bits below and see who can snoop.

Tempting idea: delete the device file and the user drops. It doesn't work — for two reasons. First, /dev/pts is a kernel-managed virtual filesystem (devpts); its entries appear and vanish automatically as ptys open and close — rm can't really remove them. Second, even deleting a device node never kills the process using it: processes hold the terminal by an open file descriptor, not by its path. The name is just a label (the same reason deleting an open file doesn't free its disk space until the program closes it).