What you actually get

You type `screen` on a server, start a long `pg_dump`, and close your laptop. The dump keeps running. That single behavior is why the tool still exists after nearly four decades, and it is also the only reason most people ever install it.

GNU Screen is a terminal multiplexer. One physical terminal becomes many virtual ones, and the whole set survives a dropped SSH connection. That is the pitch. The rest of this piece is about whether it should be your pitch.

What you actually get

A Screen session holds windows. Each window runs its own shell or application: a `psql` prompt, a `tail -f` on a log, a `vim` buffer, whatever. You switch between them with a keystroke, not a new terminal emulator tab.

Every window has a scrollback buffer. Output that scrolls off the top is still there, and `Ctrl-a {` pulls a previous line back into the prompt. On a stock SSH session that text is simply gone. You notice the difference the first time you need a stack trace that scrolled past while you were reading the top of it.

There is copy-and-paste between windows, using Screen's own buffer. It is not the system clipboard. It works over SSH, which the system clipboard does not, and it does nothing else.

The terminal emulation follows DEC VT100 with extensions from ISO 6429 and ISO 2022. In practice that means curses applications, colors, and cursor movement behave the way the application expects. This is unglamorous and it is the part that either works or ruins your day.

What persistence costs

Detach and the processes keep running. Attach later and you are exactly where you left off. A `scp` transfer, a database import, a compile — none of them care that your network died.

That is the whole value proposition, and it is worth being precise about what it is not. Screen does not restart crashed processes. It does not supervise anything. It does not survive a reboot. If the machine goes down, the session is gone, and so is the `pg_dump` you were so pleased about.

It is also not a security boundary. Anyone who can attach to your session as your user gets your session. On a shared box, that matters.

The keystroke that trips everyone

Screen's default prefix is `Ctrl-a`. That collides with the readline binding for "move to start of line," which you use constantly in bash.

You will press `Ctrl-a` to jump to the beginning of a command line, and Screen will instead sit there waiting for a second key. Then you press something else and something unexpected happens.

The fix is to pick a different prefix in `~/.screenrc`:

``` escape ^Bb ```

Now `Ctrl-b` is the prefix and `Ctrl-a` behaves like a normal readline key again. `Ctrl-b` is also what tmux uses, so if you move between the two you keep one muscle memory.

The configuration nobody writes until they have to

Screen starts with no status line worth looking at. You will want one, because otherwise you cannot tell which window you are in.

A minimal `~/.screenrc` that most people converge on:

``` escape ^Bb startup_message off hardstatus alwayslastline hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}%Y-%m-%d %{W}%c %{g}]' defscrollback 10000 ```

That `defscrollback 10000` line is not decoration. The default scrollback is small enough that you will lose output you needed, usually during an incident.

Starting, detaching, attaching

Start a named session:

``` screen -S deploy ```

Detach with `Ctrl-b d`. The session keeps running.

List what is alive:

``` screen -ls ```

Attach to a specific one:

``` screen -r deploy ```

If the session is attached elsewhere — you left it open in another terminal — you get a refusal. Use `screen -d -r deploy` to detach it from the other client and pull it to you.

Inside a session, `Ctrl-b c` creates a window, `Ctrl-b n` and `Ctrl-b p` move forward and back, `Ctrl-b "` gives you a window list, and `Ctrl-b d` detaches. That is the entire vocabulary most people ever need.

Where it sits against tmux

tmux does the same job and does more of it. Better configuration language, proper panes, a scripting interface, active development.

The comparison is not close on features. tmux wins.

Screen wins on presence. It is installed by default on more Unix-like systems than you would expect, and on the ones where it is not, it is one `apt install screen` or `pkg install screen` away on a machine that may have no package index worth trusting. When you land on an unfamiliar box at an awkward hour, `screen` is more likely to already be there than `tmux` is.

Screen's development is slow. That is a cost, and it is also why it does not surprise you. A tool that changes rarely is a tool whose behavior you can rely on from memory.

What it costs to run something simple

Screen has no panes. You get windows, and that is it. If you want two shells side by side in one terminal, you are looking at the wrong tool and you will feel it within an hour.

Screen's configuration is terse to the point of hostility. The `hardstatus` string above is a puzzle, not a document. You copy it from somewhere and adjust it once.

Screen's copy mode uses its own buffer, so pasting into another application means going through your terminal emulator's selection, which may or may not cooperate depending on how the mouse is configured.

None of these are dealbreakers for the use case Screen is actually good at. All of them are real.

The case for keeping it installed

The workflow Screen enables is narrow and it is not going away. You need a process to outlive your connection. You need a few shells in one place. You need to scroll back through output that has already left the screen.

If that is your day, Screen does it with almost no ceremony and almost no dependencies. It runs entirely in a text environment, which is what you have when you are on a headless server over SSH at 2 a.m.

If your day involves panes, scripting, and a configuration file you actually enjoy editing, tmux is the better tool and you should use it. Screen is not going to catch up, and it is not trying to.

The honest split is this: choose Screen when availability and predictability matter more than features, and choose tmux when you are on machines you control and you want the tool to keep improving. Most people end up with both installed, which is the least principled answer and probably the correct one.

The version you get matters less than you think, because the parts you rely on have not changed in years. Check `screen --version` once and then forget about it.