Command-line survival skills

Why this matters

On Day 3 you learned where files live and how to move between folders. Today you learn to operate on them — copy, rename, inspect, delete — and, more importantly, to read what the terminal says back. Command output is the only evidence you get, and reading it is the difference between fixing a problem and guessing. By the end you can meet an unfamiliar command and work out what it does unaided.

Commands, flags, and arguments

Every line you type in a terminal has the same shape — three parts, always in this order:

ls -l notes

• Command — ls. The program you want to run.
• Flag (also called an option or switch) — -l. A setting that changes how the command behaves. Flags start with a dash and are optional.
• Argument — notes. The thing the command acts on: which directory to list.

That is the whole grammar. ls alone lists the current directory in plain columns. ls -l lists the same files in long form — one per line with size, date, and permissions. Same command, same files, different behaviour. That is precisely what a flag is for.

Short flags are one dash and one letter — -l, -a — and usually stack, so ls -la equals ls -l -a. Long flags are two dashes and a word: --version, --help. You used one on Day 2 when you ran node --version.

What the command says back

A command can write to two separate output channels. Both land on your screen, which hides that they are different.

• Standard output (stdout) — the normal result, what the command produced when it worked.
• Standard error (stderr) — complaints: errors, warnings, anything that went wrong.

They stay apart so you can send the result somewhere while still seeing problems. > redirects stdout into a file; 2> redirects stderr.

ls missing.txt > out.txt

ls: missing.txt: No such file or directory

You redirected stdout to out.txt, yet the error still appeared on screen — it travelled on stderr, which you did not redirect. out.txt will be empty. (Linux words the message slightly differently: cannot access 'missing.txt'. Same channel, same lesson.)

A third signal is invisible unless you ask: the exit code. Every command finishes with a number — 0 for success, anything else for failure. Ask for the last with echo $?.

ls missing.txt
echo $?

ls: missing.txt: No such file or directory
1

Help and history

You do not memorise commands; you interrogate them. Most modern tools answer --help with a usage summary: the shape of the command and the flags it accepts.

node --help

The classic macOS/Linux utilities (ls, cp, mv, rm) predate that convention; on macOS, cp --help prints an illegal option complaint and a usage line instead. For those use the manual: man cp opens a scrolling page — space to scroll, q to quit, the most common "how do I get out of here?" moment for beginners. (PowerShell: Get-Help cp.)

The shell also remembers what you ran. Up arrow recalls the previous command, history prints recent commands numbered, and Ctrl+R reverse-searches them by any fragment. History is how you reconstruct what you actually did when something breaks.

Walkthrough: five operations, each one verified

Work in a disposable folder so nothing valuable is at risk:

cd ~/fullstack-journey
mkdir cli-practice
cd cli-practice

echo prints its argument to stdout; > sends that stdout into a file instead of the screen.

echo "pump 3 replaced seal" > log.txt
cat log.txt

pump 3 replaced seal

cat prints a file's contents to stdout. Now copy, rename, and inspect:

cp log.txt log-backup.txt
mv log-backup.txt archive.txt
ls -l

-rw-r--r--  1 you  staff  21 Aug  3 10:14 archive.txt
-rw-r--r--  1 you  staff  21 Aug  3 10:13 log.txt

cp copies (the original stays), mv moves or renames — renaming is moving to a new name in the same folder. Both files are 21 bytes: 20 characters plus the newline echo added. The -l flag turned a list of names into evidence. Now count lines, then delete:

wc -l log.txt
rm archive.txt
ls

       1 log.txt
log.txt

Working with AI today: pair mode

Day 3 was human-only. Today's mode is pair — AI as a pair programmer, not a vending machine: it proposes, you verify. The rule that makes this safe is inspect the change, run your checks, and be able to explain the behaviour before accepting anything an AI produces. Not "it looked plausible". Accept nothing you cannot narrate line by line.

Your turn

Build cli-log.md, recording each command and its effect in your own words.

1. In ~/fullstack-journey/cli-practice, create a.txt and b.txt. Confirm with ls.
2. Put text in a.txt with echo "..." > a.txt; confirm with cat a.txt.
3. Copy a.txt to a-copy.txt with cp, then rename it to b-final.txt with mv. Confirm with ls -l — check the byte size matches the original.
4. Run something you know will fail, like cat nope.txt. Record the exact error text and the result of echo $?.
5. Pick a command you have never used — head, tail, or du — and run --help or man on it before running it. Write one sentence on what it does, from the docs, in your words.
6. Run history, find the step 3 commands, and re-run one using the up arrow.
7. Delete the practice files with rm and confirm with ls.
8. Write cli-log.md in ~/fullstack-journey: one line per command, its flags and arguments named, and the effect you observed.

Common pitfalls

• Confusing a flag with an argument. rm -r notes removes the folder notes recursively; rm -r alone does nothing. The dash tells you which is which.
• Assuming silence means failure. cp and mv print nothing on success. Verify with ls, not by staring at an empty line.
• Scrolling past the error. It names the file and the reason. Read it word by word first.
• Expecting --help everywhere. BSD tools on macOS often reject it; reach for man.

Verify it yourself

Open today's reference, MDN's Command line crash course, and find where it explains command options and arguments.

1. MDN describes at least one command this lesson did not cover. Pick one, read only the docs, write what it does in cli-log.md, then run it and check you were right.
2. Which of "flag", "option", and "switch" does MDN prefer? Note it — different docs use different names for the same thing, and recognising that is part of reading docs fluently.