Terminal.Drill Get the app
ch00/l01

Terminal, shell, prompt

Separate the terminal window from the shell process, then read the prompt as state.

whoami && hostname && pwd 15 min read, 15 min lab beginner

A terminal is the interface. A shell is the program reading commands. A prompt is a compact status line: user, host, current directory, privilege level, and often Git or virtual environment context. Good terminal work starts by reading that state before typing.

In the field

You are handed an SSH session during a service incident. Before touching the service, prove which host, user, and directory you are in.

Worked command

$ whoamistudio-dev$ hostnameops-lab-01$ pwd/home/studio-dev/work$ echo "$SHELL"/bin/zsh
Anti-pattern

Do not assume the prompt theme is accurate enough to act on. Confirm the state with commands when the consequence matters.

Safer pattern

Build a habit: identity, host, path, then command.

Knowledge check

An SSH prompt reads root@prod-db:/var/lib before a destructive command. What does that prompt establish on its own?

  • A Proof you are root on prod-db in /var/lib, safe to proceed
  • B Nothing reliable; confirm user, host, and path with commands first
  • C Only the shell type, since prompts never show the directory
  • D That the previous command succeeded, since the prompt redrew
Show the answer

Correct: B. Nothing reliable; confirm user, host, and path with commands first

Why

The prompt is a theme-driven status line (PS1) that can lie or lag, so identity, host, and path must be confirmed with whoami, hostname, and pwd when the consequence matters. Treating the displayed prompt as proof is exactly the assumption that destroys the wrong host.

Practice checklist

  1. Open a disposable shell session.
  2. Run whoami, hostname, pwd, and echo "$SHELL".
  3. Write one sentence describing the session state.

Deliverable evidence

  • A prompt-state note with user, host, path, shell.
  • One thing the prompt shows and one thing it does not prove.
Teaching diagramch00 · mental model
read state, then act, then read the result1. prompt statewhoami / hostnamepwd / $SHELL2. command shapecmd -opts argsverify: man / --help3. exit statusecho $?0 ok / non-zero stopread stderr firstnon-zero?prompt theme shows, it does not prove

shows: The chapter's operator loop: read prompt state, parse the command into executable/options/arguments and verify it, run it, then read exit status and stderr before the next move.

does not prove: It does not prove a zero exit status means the intended effect happened, nor that the prompt's displayed host, path, or privilege are accurate; both must be confirmed with commands when consequences matter.

Memorize this

Commit these to memory, then drill them until recall is automatic.

whoamihostnamepwd$SHELL

Reference

whoamihostnamepwdechohistory
Recall practice · Scenario -> next check

cue Before any destructive command, which three facts do you verify with commands rather than trust from the prompt?

show recall target

identity (whoami), host (hostname), path (pwd)

See this drill type Practice recall in the app