Recording Terminal Sessions with the script Command

If you’ve ever tried to explain “what happened in the terminal” after the fact—during an incident, a tricky migration, or a support handoff—you’ve probably wished you could rewind time. The Unix script command is the low-tech, high-value answer: it records an interactive terminal session so you can keep an audit trail, share reproducible steps, or just stop relying on screenshots.

script has been around forever, ships on most Linux distributions, and exists on macOS and other Unix-like systems (often with slightly different flags). It’s one of those tools that feels boring right up until it saves you.

What script does

At a high level, script starts a new shell (or runs a command) inside a pseudo-terminal (PTY) and copies everything that appears on your screen into a file.

That means it captures:

• Commands you type (as they appear on the terminal)
• Program output
• Prompts
• Interactive programs (to a point)

It also means it often captures terminal control sequences (colors, cursor movement, progress bars). That’s not a bug—it’s the reality of recording a screen-oriented interface.

The simplest way to use it

Record a session to a file:

Do your work, then exit the subshell (or press Ctrl-D). You’ll see a start and end message, and the session is written to session.log.

A very common improvement is append mode so you can keep a running file:

Practical flags you’ll use a lot

Different platforms implement script a little differently, so treat this as “common patterns” and confirm with man script on your system.

Append instead of overwrite

Record a single command

This is great for grabbing “exactly what I ran and what it printed” without an interactive shell:

• -c runs a command
• -q quiets the “Script started/stopped” messages

Flush output as you go

If you’re recording something long-running and you want the log updated in near-real-time:

Capture timing for replay

On many Linux systems (util-linux), script can also save a timing file so you can replay the session with realistic delays:

Then replay it:

If your script doesn’t support timing flags, you can still record the raw session; you just won’t get “movie-style” playback.

Examples sysadmins actually use

1) Capture change steps for a ticket or postmortem

Do your maintenance, paste key outputs into the ticket later, and keep the full transcript archived.

2) Record an interactive troubleshooting session (safely)

When you’re pairing with someone asynchronously, a transcript beats “I think I typed…”

3) Record a remote session (SSH) from your side

This keeps the log on your machine, which is often easier to retain and attach to documentation.

4) Build reproducible runbooks

Start the session, then intentionally run through the “golden path” with commentary:

Later, you can distill the transcript into a cleaned-up runbook.

Reading and cleaning up script output

Because terminal output isn’t plain text, your log may contain ANSI color codes and cursor movement.

Helpful ways to view it:

• less -R session.log (keeps color codes readable)
• cat session.log (works, but can look messy with control characters)

To convert to “mostly plain text,” you may need to strip control sequences. Tools vary by platform, but you’ll often see people reach for:

• col -b (removes some backspaces/control chars)
• Dedicated “ANSI to text” filters

When accuracy matters, prefer viewing the original and only generate a cleaned copy for sharing.

Security and privacy: the part you should not skip

script is extremely good at recording things you didn’t mean to keep.

Before you hit enter on anything sensitive, consider:

• Secrets can appear in command output (tokens, environment variables, config dumps).
• Some password prompts disable terminal echo (so the password itself usually won’t show), but that’s not a guarantee for all tools or all secret entry methods.
• Clipboard pastes of secrets can end up in the log if they’re echoed to the terminal.

A few safer habits:

• Avoid commands that print secrets (env, verbose config dumps) during recording.
• Prefer secret managers and tools that don’t echo secrets to stdout.
• If you must handle secrets, stop recording, do the secret step, then restart script.
• Treat the resulting log like a sensitive artifact: correct permissions, secure storage, sane retention.

Best practices

• Name logs like you mean it: include date, system, and task.
• Use -a for long-running work so you don’t overwrite a previous run.
• Use -f when someone is tailing the log, or you want crash-safe progress.
• Use -c for “single command, single artifact” workflows.
• After the fact, extract key outputs (versions, diffs, checks) into your ticket/runbook, and keep the raw transcript as backup.

Common gotchas

• Interactive full-screen programs (like editors, top, less) can record poorly or produce very noisy logs.
• Progress bars and spinners can create huge transcripts because they repeatedly redraw the same line.
• Terminal resizing during recording can make playback confusing.
• Some shells or tools detect PTYs and slightly change behavior (for example, colored output or line wrapping).

Alternatives (and when to use them)

• asciinema: purpose-built terminal recording, great for shareable demos.
• ttyrec / termrec: older PTY recorders with different tradeoffs.
• tee + non-interactive commands: best when the command doesn’t need a TTY.

If you need a clean, shareable “terminal movie,” use asciinema. If you need a dead-simple transcript on a box that already has core utilities, script is hard to beat.

Quick checklist

• Confirm flags available on your OS: man script
• Decide where logs live and how long you keep them
• Avoid recording secrets
• Use append + flush when you need reliable artifacts
• Summarize key results separately; keep the transcript as evidence

If you start using script regularly, you’ll notice something: your incident notes get better, your handoffs get easier, and “what did we do?” stops being a mystery.