A Linux terminal command sheet for web developers

The terminal becomes much less intimidating when each command answers a specific question: where am I, what am I changing, and did it work? This command sheet turns those questions into a small exercise before you use the same ideas on a VPS.

Use Bash on an Ubuntu 24.04 or 26.04 test machine you control. The examples use GNU utilities; macOS options can differ. None requires administrator access. Commands are syntax-checked examples, not a claim that a complete Ubuntu server was provisioned for this article. Start with the VPS learning path for the wider deployment sequence.

Know which computer and account you are using

An SSH session is a shell on another computer. A command that creates a file there does not create it on your laptop. Start a session by identifying its context:

hostname
whoami
pwd
printf '%s\n' "$SHELL"
ps -p $$ -o comm=
command -v bash

pwd prints the current directory. $SHELL normally describes your login shell; the process check helps identify the shell actually running. A prompt ending in a dollar sign is a convention, not an authorization check. Do not paste a leading prompt character from somebody else's screenshot.

Absolute paths start with /. Relative paths start from your current directory. . means the current directory and .. its parent. Before working on an application, check pwd instead of trusting an old terminal tab.

Build a disposable practice directory

practice_dir="$(mktemp -d)"
printf 'Practice directory: %s\n' "$practice_dir"
cd "$practice_dir" || exit 1
mkdir notes
printf 'ready\nwaiting\nready\n' > notes/status.txt
printf 'Release checklist\n' > "notes/release notes.txt"
ls -lah notes

mktemp -d creates a unique directory. Keep the printed path if you want to return to it later. Quote variable expansions and filenames containing spaces: without quotes, the shell may split one intended argument into several. printf gives predictable formatting; its first argument is the format, and later arguments supply data.

The single > creates or truncates a file. Running that line again replaces its previous contents. >> appends instead, which is useful for a practice log but still changes the file. Neither is a substitute for a backup. Ubuntu's terminal introduction explains navigation and redirection with further exercises.

Inspect a file without changing it

cat notes/status.txt
sed -n '1,2p' notes/status.txt
tail -n 2 notes/status.txt
wc -l notes/status.txt
grep -n -- 'ready' notes/status.txt

Expect three lines overall, with ready on lines 1 and 3. sed prints a bounded range; tail reads the end. On a large log, choose a bounded read or less rather than dumping everything. In less, /error searches and q exits. A terminal scrollback is not a secure place to display passwords, tokens or customer records.

The -- tells supporting commands that subsequent arguments are not options. Here it protects a search pattern that could otherwise begin with a hyphen. It is not universal shell syntax: consult the particular command's manual.

Use pipes and check failures

sort notes/status.txt | uniq -c
if grep -q -- 'ready' notes/status.txt; then
  printf 'At least one ready record exists.\n'
else
  printf 'No ready record, or the search failed.\n'
fi

A pipe connects standard output from one command to standard input of another. The first line should count two ready records and one waiting record. This is a learning fixture, not a parser for arbitrary application logs.

An exit status of zero conventionally means success. Nonzero needs interpretation: grep uses 1 for no match and a different status for an error. The simple conditional intentionally groups those cases; production automation should distinguish them where it matters.

false | true
printf 'Default pipeline status: %s\n' "$?"
set -o pipefail
false | true
printf 'With pipefail: %s\n' "$?"
set +o pipefail

Expect 0, then a nonzero status. Bash normally reports the final command's status; pipefail makes an earlier failed stage count too. Run this as an interactive exercise, not inside an existing set -e script. Read the Bash manual before combining shell error-handling options: they have context-dependent behaviour, not universal transaction semantics.

Find commands and inspect changes

type -a printf
command -v node
cp -i -- notes/status.txt notes/status-before.txt
printf 'complete\n' >> notes/status.txt
diff -u -- notes/status-before.txt notes/status.txt

type distinguishes built-ins, functions and executable files. command -v node may fail if Node is not installed; do not install random software merely to make an exercise green. diff returns 1 when files differ, so that result is expected here. Review the added line, not just the exit code.

Leave the practice folder in place until you have finished inspecting it. To remove it later, use your file manager and the exact printed path, not a broad recursive command copied without context.

Carry the habit into deployment

Before a change, identify the machine, account and path; inspect existing state; understand whether the command reads, writes or restarts; then verify its effect. Keep a private operational record, redacting sensitive output before sharing it. Shell history is a convenience, not a complete audit log or secret store.

Continue with application file permissions and finding ports and processes. If you need a deployment handed over with this level of explanation, CodeKits development services can include an app-specific command sheet.