TerminalVibes — The Terminal for Vibe Coders

First Contact

The terminal has a fearsome reputation, so let's start by deflating it: it's just an app. It sits next to your browser and your music player, it opens like them, and it closes like them. Here's where to find yours.

macOS

Press ⌘ Space — hold Command and tap Space — to open Spotlight, the macOS search bar. Type Terminal, press Enter. That's it. (The long way: Applications → Utilities → Terminal.app.) The stock app is a genuinely good place to start — since macOS 26 "Tahoe" it has true color and modern themes, so there's nothing to install today. Pin it to your Dock while it's running (right-click its icon → Options → Keep in Dock) — you'll be back.

Linux

Press Ctrl+Alt+T on most desktops, or find Terminal / Console in your application menu.

Windows

Open Windows Terminal from the Start menu — it's been the default console since Windows 11 22H2, so it's already there — then pick your Ubuntu (WSL) profile from the dropdown next to the new-tab button. If you chose Git Bash instead, open Git Bash from the Start menu. Either way, make sure you're in a bash window — not PowerShell — before following along (the intro explains the difference).

Whatever you opened, you should now be looking at a mostly-empty window with a prompt and a blinking cursor — the shell, waiting for your first words.

A command is a word — sometimes followed by more words — typed at the prompt. Nothing happens while you type. Nothing happens while you hesitate. The shell only acts when you press Enter. Let's have your first conversation.

Start with a question the machine can't get wrong — who are you? In every code block from here on, the first line is what you type and the # lines are the machine's reply (Introduction has the full legend).

whoami
# vibe

The shell answered with your username. Now make it say something — echo repeats whatever you give it, and the quotes hold the two words together as one message instead of two separate ones (Paths has the rule):

echo "Hello, terminal"
# Hello, terminal

Ask for the time, and then wipe the slate clean:

date
# Sat Jul 12 10:15:42 PDT 2026

clear
# The screen empties - the text is still there, just scrolled out of sight

The screen went blank but nothing was deleted: that's the terminal's scrollback, and scrolling up brings every answer back. The shell also keeps its own record of the commands you typed (History Superpowers) — a separate list, and clear leaves that alone too.

Now the important experiment: type something wrong on purpose. Misspell a command and press Enter:

ecoh "hello"
# bash: ecoh: command not found

Read that reply back like a sentence in three parts: bash is who's complaining — the shell, not your command — ecoh is the word it choked on, and command not found is the complaint. Every error you meet from here on has that shape; only the complainer changes.

Try It: Say Hello to the Machine

You will never memorize every command — nobody does. What experienced people memorize instead is how to look things up. The terminal ships with its own documentation, and it's always three keystrokes away.

Two ways in, and you'll use both. --help prints a compact summary of what a command does and which flags it accepts, straight to your terminal. man opens the full manual. Which one answers you depends a little on your machine — we'll get to that — but between them, nothing stays a mystery for long.

Flags first, because that summary is mostly a list of them. A command line is a sentence. The first word is the program. Everything after it is either a flag — a request to behave differently — or an argument, the thing to act on. The shell tells them apart by one character: a leading dash. ls -a means "run ls, and switch on the a behaviour". ls a means "run ls on something called a", which is a different question entirely and usually an error. That dash is doing real work; it is not decoration.

The shell chops your line at the spaces and hands over the pieces one at a time, which is why a filename with a space in it needs quoting. Four rules cover almost everything else you'll meet:

• One dash, one letter. -a, -l. Short, fast, and what you type day to day.
• Two dashes, a whole word. --all, --help, --version. Longer to type, far easier to read six months later in a script.
• A comma joins two spellings of the same flag. When help output or a manual page prints -a, --all, that is one flag with two names. Use either. Never both.
• Single letters cluster. ls -la is ls -a -l written faster; add a t — ls -lat — and you've asked for them sorted newest first as well. Only single letters cluster this way; --all --long doesn't squash into anything.

ls --help
# Usage: ls [OPTION]... [FILE]...
# List information about the FILEs (the current directory by default).
#   -a, --all        do not ignore entries starting with .
#   -l               use a long listing format
# ...

That Usage: line has a shorthand of its own: square brackets mean optional, ALL-CAPS words are placeholders you swap for your own, and a trailing ... means "as many of these as you like". OPTION is the older word for a flag and you'll see both, often on the same page. So ls [OPTION]... [FILE]... reads: any number of flags, then any number of files, none of it required. Nothing in brackets is ever typed literally.

On a Mac, that same command is an error — and that's fine

Mac and Linux carry two different lineages of the same veteran tools. macOS ships BSD's versions; Linux — and WSL and Git Bash with it — ships GNU's. GNU tools nearly all answer to --help. Most of the BSD ones have never heard of it, and say so:

ls --help
# ls: unrecognized option `--help'
# usage: ls [-@ABCFGHILOPRSTUWXabcdefghiklmnopqrstuvwxy1%,] [--color=when] [file ...]

Same three parts as ecoh earlier, and the same reassurance: nothing broke, and you weren't punished for trying. Here the complainer is ls rather than the shell — it names the one thing it didn't understand, then prints its usage line anyway — so you still got the flag list, just terser and stripped of the descriptions. That's the shape of most terminal errors. Read the words; they usually say precisely what tripped them up.

ls, du, head, cut, wc, stat and date all behave this way on a Mac. So does grep, which quietly prints its usage line without even calling it an error. The tools you install yourself later — curl, git, tar, jq, brew — take --help everywhere, Macs included. For everything else on a Mac, the answer is the manual.

This course uses angle brackets for the same job — when you see man <command>, you type man ls, never the brackets. That matters more in a shell than elsewhere: < is a real operator in its own right, so typing the brackets produces an error that points nowhere near your mistake.

For the full story — and, on a Mac, for most of the built-in commands — there's man — the manual, installed with your system since before the web existed. It comes in numbered sections, because one name can mean two things: crontab is both a command you run and a file format that command reads, so man 1 crontab and man 5 crontab are two different pages. Section 1 is commands, section 5 is file formats. Leave the number off and you get the first match, which is nearly always the one you meant:

man ls
# Opens the complete manual page for ls

man -k download
# wget(1) - The non-interactive network downloader.
# ...

The second is for when you don't know the command's name yet. -k is for keyword: it searches every manual page's one-line description and prints each match with its section number in brackets. Your machine will list many more than this one.

Worth knowing where that search stops, though, because it will bite you. It reads only that one-line description, not the page. curl downloads files for a living, and man -k download does not find it — its description reads transfer a URL, and the word "download" appears nowhere in it. So a -k search that comes back thin means your keyword didn't match anyone's phrasing, not that no such command exists. Try a synonym before you conclude anything.

Man pages are thorough but dense. For a friendlier take, the community-written tldr pages — too long; didn't read — show each command as a handful of practical examples. tldr doesn't come with your system, though: it's a third-party command you install first (Package Managers). Nothing to install to read it, happily — the web version is at tldr.inbrowser.app, which is where the output below comes from.

tldr tar
# tar
#   Archiving utility.
#   - Create an archive from files:
#     tar cf target.tar file1 file2 file3
#   - Extract an archive to the current directory:
#     tar xf source.tar
# ...

Those cf and xf look like they've lost their dash, and they haven't: tar is old enough to accept its letters bare, so tar cf and tar -cf are the same command. It's one of the few commands in this course that gets away with it — assume the dash everywhere else.

A third way to get help

You have a third source of help the man-page authors never imagined: paste any command into your AI assistant and ask "what does this do, flag by flag?" It's the fastest explanation you'll get — and it works in reverse too, when the AI is the one proposing the command. The AI vendors know it: Anthropic's Claude Code docs now ship their own "never opened a terminal before" guide — if you use a coding agent, being able to read its commands is part of using it safely. But language models can be confidently wrong about flags, so close the loop:

Try It: Read the Manual First

Moving Around: Your Mental Map of the Machine

A fresh terminal window is quiet: a prompt, a blinking cursor, and no other clues. But you're not floating in a void — the shell has already placed you inside a folder, called your working directory. Two commands turn the void into a map.

pwd ("print working directory") answers the question in one line:

pwd
# /home/vibe

That answer — /home/vibe — is a path, the full address of the folder you're standing in (paths get their own section next). It also names your home directory — the folder that belongs to your account, where your files, settings and downloads live. Every account on the machine gets one, and this one is the home of the account named vibe — you. Now look around with ls ("list"):

ls
# documents  notes.txt  projects

The Hidden Layer: Dotfiles

Plain ls is holding out on you. Any file or folder whose name starts with a dot — a dotfile — is hidden by default. That's where configuration lives: .bashrc, your shell's own settings file (Your Shell Config); .gitignore; and the .env file holding your API keys — an API being a door a service opens for other programs rather than for people, which is why that file is worth hiding (curl — Ask the Network). Add -a ("all") to see them:

ls -a
# .  ..  .bashrc  .config  documents  notes.txt  projects

A First Peek at ls -l

The long listing packs a lot into each line. For now, read just three things: the leading d means "directory," the number before the date is the size in bytes, and the name is at the end. A byte is one character's worth of storage, so a 118-byte file holds roughly 118 characters. The rest of that cryptic string is the permissions code, and we decode it fully in Permissions & Config.

ls -l
# total 12
# drwxr-xr-x  3 vibe staff 4096 Jul 10 09:14 documents
# -rw-r--r--  1 vibe staff  118 Jul 12 08:30 notes.txt
# drwxr-xr-x  4 vibe staff 4096 Jul 11 17:02 projects

Three things in that block mislead on sight. total 12 is not a count of the files — it's how much disk they take up, measured in blocks rather than bytes. The small number just after the permissions is a link count, not a second size. And the two names beside it, vibe staff, are the file's owner and its group. All three get taken apart in Reading ls -l.

Every file on your machine has an address, and that address is called a path. Learn to read paths and the whole filesystem snaps into focus — it's one big upside-down tree, and you can point at any leaf from anywhere.

Everything starts at the root, written as a single slash / — the one folder every other folder lives inside. Everything else hangs somewhere beneath it, and a path is the walk from one point to another, with / between each step. Fair warning, because the word gets reused: this root is a place. The other root you'll meet is a person, the administrator account in sudo, and the two have nothing to do with each other.

Reading the tree: the file .env lives at /home/vibe/projects/app/.env — root, then home, then vibe, then projects, then app.

The branches sitting beside home at the top belong to the machine rather than to you, and a handful come up often enough to name. /bin and /usr/bin hold binaries — the programs themselves. /etc holds system-wide configuration — that's what /etc/hosts in the table below is, the short list of names your machine resolves itself before asking the network. /tmp is scratch space anyone can write to and the machine may clear without asking. And /usr, despite the spelling, is where the system's own software lives — it has nothing to do with users.

Absolute vs. Relative

An absolute path starts at the root with / and works from anywhere — a full street address. A relative path starts from wherever you're currently standing — "two doors down." Both name the same file:

# Absolute: works no matter where you are
cat /home/vibe/projects/app/README.md

# Relative: works if you're standing in /home/vibe
cat projects/app/README.md

The Four Shortcuts Every Path Uses

And they compose. Standing in ~/projects/app, the path ../../documents means "up two levels, then into documents." Now you can re-read the AI's instruction: ~/projects/app/.env is a hidden file named .env, inside app, inside projects, inside your home directory.

Those quotes are worth understanding properly, because you'll be reaching for them for the rest of the course. There are two kinds, and one difference that matters. Single quotes are literal — nothing inside them means anything to the shell, so '$HOME' stays five characters instead of turning into the path to your home directory, and '*.txt' stays five characters instead of becoming a list of files. Double quotes still let $NAME and $(...) expand into their values (Environment Variables) while still protecting the spaces. Reach for single quotes when you want the shell to keep its hands off, double quotes when you want a value in the middle of a phrase.

A backslash does the same job for exactly one character: My\ Projects is one filename, not two words — which is what TAB completion is doing when it "escapes" a space for you. Anything the shell would otherwise read as punctuation — a space, a *, a $, a quote mark — can be defused by putting a backslash in front of it.

Try It: Mind the Gap

You can read the map; now walk it. cd ("change directory") moves you to any path you can name — and since you just learned to name every path on the machine, you can now go anywhere.

cd projects/app   # Walk down into a folder (relative path)
pwd               # /home/vibe/projects/app — always verify
cd ..             # Up one level, to projects
cd ~              # Jump home from anywhere (plain 'cd' does the same)
cd -              # Bounce back to wherever you just were

That last one is a gem most tutorials skip: cd - toggles between your two most recent locations — perfect when you're hopping between a project and a config folder. It's also one of the rare places a lone dash is a value rather than a flag (Getting Help) — here it stands in for "the last place I was," not for a setting. And remember the habit from 2.2: type cd, a few letters, then TAB your way down the tree.

Try It: Find the Lost API Key

So far you've been a tourist — looking, never touching. Time to build. Two commands create the skeleton of every project you'll ever start: mkdir for folders and touch for empty files.

mkdir notes            # One new folder in the current directory
mkdir src tests docs   # Three at once — src is short for "source"
touch README.md        # One new, empty file
ls                     # Verify — trust, but verify

Plain mkdir has one rule: the parent must already exist. Ask it for a nested path and it refuses:

mkdir src/components/buttons
# mkdir: cannot create directory 'src/components/buttons': No such file or directory

mkdir -p src/components/buttons   # -p = parents: create every missing one on the way
# (no output — in the shell, silence means success)

touch has a funny origin story: its real job is updating a file's "last modified" timestamp — touching it. But if the file doesn't exist, touch creates it, empty. That side effect became its main job: it's the standard way to say "make me a blank file right here."

mkdir -p my-app/src/components my-app/tests
touch my-app/README.md my-app/src/main.js
ls -R my-app   # -R walks into every folder inside, and those folders' folders too

Nothing on the machine requires that shape — src, tests and docs are a convention other people will recognize, not a rule anything enforces. And that walking-into-everything behaviour has a name, recursive, which comes back in Copying as the flag that lets copying and deleting reach a whole tree at once.

An AI agent just wrote a config file into your project. Before you trust it, you want to read it — without the ceremony of opening an editor. The terminal has a whole toolkit for exactly this, graded by file size.

cat config.yaml
# port: 8080
# debug: false
# database: ./data/app.db

That file is YAML — a config format built to be read by humans, one key: value to a line. (A config file being any file that changes how a program behaves without changing the program itself.)

A few other extensions keep turning up and work the same way. .csv is comma-separated values: one record per line, the fields split on commas, the first line usually naming the columns. .md is Markdown — plain text with light formatting marks, like # for a heading. .sh is a shell script. Every one of them is ordinary text underneath: a file of characters, each character stored as a number. That's why the commands below read all of them equally well, and why an extension is a convention for humans and editors rather than the thing that makes a file work.

cat (short for "concatenate") is perfect for short files — it prints everything and returns your prompt. But cat a 10,000-line log and it firehoses past you. For anything long, you want a pager:

less server.log
# Opens a full-screen reader:
#   space / b     page down / up
#   arrow keys    scroll line by line
#   /error        search for "error" — press Enter to run it (n = next match)
#   q             QUIT — back to your prompt

While we're here, four escape hatches worth memorizing now — because each one has stranded somebody for an embarrassingly long time. Two are characters you type; two are chords, held down together in one motion. The comments say which is which:

q            # type it — any pager: less, or a man page. One keypress, no Enter
:q!          # type it — vim. Press Esc FIRST, then these three, then Enter (:wq saves instead)
Ctrl+X       # chord — nano. It says so at the bottom, but nobody reads it
Ctrl+C       # chord — a running command, or a line you typed but haven't run

:q! is the famous one. Git — the tool that records snapshots of a project as you work (Your Shell Config) — drops you into vim on most machines to write the note that goes with a snapshot. The keyboard stops behaving, there's no visible way out, and the answer is Esc then :q! then Enter, which leaves without saving. You are not expected to learn vim today; you're just expected to be able to leave.

Sometimes you only care about the edges of a file — the header row of a CSV, or the most recent lines of a log. That's head and tail:

head server.log        # First 10 lines
head -n 3 server.log   # First 3 lines
tail server.log        # Last 10 lines — where the newest log entries live
tail -n 20 server.log  # Last 20

Try It: Build Your Workspace

Copy, Move, Delete — and the Habits That Keep You Safe

Copying is the gentlest of the three power tools — the original is never touched. It's also your cheapest insurance policy: one cp before an experiment means there's always a way back.

cp always reads the same way: source first, destination second — "copy this, to there." What "there" means depends on what the destination is:

# Destination is a new name: copy + rename in one step
cp config.yaml config.yaml.bak

# Destination is an existing folder: copy INTO it, same name
cp config.yaml backups/

Copying Folders Needs -r

Ask cp to copy a directory and it declines — a folder can contain thousands of files, and cp wants you to say you mean it:

cp projects backup-projects
# cp: -r not specified; omitting directory 'projects'

cp -r projects backup-projects   # -r = recursive: the folder and everything inside

Here's a small mind-bender: the terminal has no "rename" command, because it doesn't need one. Renaming is moving — moving a file to a new name in the same place. One command, mv, does both.

Like cp, it's always source first, destination second — and the same two shapes:

# Destination is a new name: RENAME
mv untitled.py main.py

# Destination is an existing folder: MOVE into it
mv sales.csv users.csv logs.csv data/

# Both at once: move AND rename
mv draft.md docs/chapter-1.md

The middle line is the fine print behind "source first, destination second": once you name more than two things, the last one has to be a folder, and it has to exist already. Neither cp nor mv will make one for you — with no docs/ yet, the last line stops at No such file or directory, and you fix it with mkdir docs and run it again.

Two nice surprises compared to cp: mv moves whole folders without needing -r (on the same disk it just relabels the folder's address — instant, even for gigabytes), and since nothing is duplicated, there's no copy lying around to get stale. Move to a different disk, though — an external drive, a USB stick — and mv quietly becomes a full copy followed by a delete: slow, and interruptible halfway through.

This is the most important safety lesson in the entire course. Everything else in the terminal is forgiving — errors are harmless, cd can't hurt you, cp leaves originals alone. rm is the exception. Read this section twice.

rm old-notes.txt        # Delete one file. Permanently.
rm draft1.md draft2.md  # Delete several
rmdir empty-folder      # Delete a folder — only works if it's EMPTY
rm -r old-project       # Delete a folder and everything inside it
rm -f missing.txt       # -f = force: no complaints if it doesn't exist

Each flag is reasonable alone. -r recurses into folders; -f suppresses prompts and "no such file" errors so scripts run clean. Combined as rm -rf, they mean: delete everything at this path, recursively, without asking, without stopping. Now add the two ingredients from your recent lessons and you have the terminal's most famous disaster recipe:

A single mistyped space does it too: rm -rf old-app / (note the stray space) is not "delete old-app/" — it's "delete old-app, and also the entire filesystem starting at root." This exact typo has destroyed production servers. It's why modern systems refuse plain rm -rf / without an extra flag — but they won't save you from ~ or a wrong folder.

The Ritual: ls First, Then rm

Here's the habit that makes rm boring instead of scary. Never aim rm at anything you haven't just looked at. List first, confirm with your eyes, then recall the command (up-arrow) and swap ls for rm — same targets, guaranteed:

ls old-project          # 1. LOOK: what exactly is in there?
pwd                     # 2. CONFIRM: am I where I think I am?
rm -r old-project       # 3. Same target you just inspected — up-arrow, edit, Enter

Try It: Clean the Downloads Mess

Everything so far has operated on files one name at a time. Wildcards — also called globs — let one pattern stand for many names: "every .log file," "all the photos from January." This is where selecting files by hand in a file manager starts to feel slow.

The Big Idea: the Shell Expands the Glob, Not the Command

This is the one concept that makes wildcards predictable instead of magical. When you type rm *.tmp, the rm program never sees a star. The shell expands the pattern against the current directory first, then runs the command with the resulting list of plain filenames:

Two consequences follow directly. First, what a glob matches depends entirely on where you are — the same *.tmp is three files in one folder and three hundred in another (this is the wildcard half of the rm -rf disaster from Deleting (Carefully)). Second, since expansion happens before any command runs, you can ask a harmless command to show you the expansion:

echo *.tmp
# cache1.tmp cache2.tmp scratch.tmp    <- exactly what rm would receive

rm *.tmp                               # Now you KNOW what this deletes

Globs compose with everything you already know — they're just a way of writing file lists:

cp *.md drafts/           # Copy every Markdown file into drafts/
mv photo-0?.jpg january/  # Move photo-01.jpg through photo-09.jpg
ls report-[12].txt        # List just report-1.txt and report-2.txt
ls src/*.js               # Globs work inside a path too — but only one folder deep

That last line is where globs stop: one never crosses a /. src/*.js looks inside src and gives up there — it will not find src/lib/util.js, and no arrangement of stars will make it. When a mess is spread down through subfolders the pattern is the wrong tool, and walking a whole tree is find's job: find . -name '*.tmp' would have caught those 40 files wherever they'd landed. It has a section waiting in Finding Files.

Try It: Select Exactly the Right Files

Text & Pipes: How Small Tools Combine

Every command writes its results to something called standard output — which is normally your screen. Redirection says: "don't print that, put it in a file instead." One character does it: >.

echo "hello" > greeting.txt      # Create the file (or OVERWRITE it!)
cat greeting.txt
hello

echo "hello again" >> greeting.txt   # >> APPENDS to the end
cat greeting.txt
hello
hello again

Standard output isn't the only channel — every command is born with three. Standard input (stdin) is where it reads from, normally your keyboard; standard output (stdout) is where its results go; and standard error (stderr) is a separate channel for its complaints, kept apart so a failure never gets mixed in with the results. They're numbered 0, 1 and 2 — which is the whole story of the 2 in 2>. A plain > captures stream 1 only, so errors still land on your screen. To catch those too:

ls reports/ missing/ > listing.txt 2> errors.txt

cat listing.txt      # The successful part
q1-summary.md
q2-summary.md

cat errors.txt       # The complaint went to its own file
ls: missing/: No such file or directory

You'll also meet > all.log 2>&1 in AI-generated commands, and it reads left to right: send stream 2 to wherever stream 1 is currently pointing, which the first half of the line has just set to all.log. The &1 is what makes it a reference to a stream rather than a filename — drop the & and you create a file called 1. Finally, the arrow points the other way too: < feeds a file into a command as its input, as in sort < names.txt. It's rarer — most commands happily take a filename argument — but it completes the picture: arrows move text in and out of files.

One member of the family points both ways at once. tee — named for the T-shaped pipe fitting, and it is exactly that — sits in the middle of a stream, writes everything flowing through it into a file, and passes the same text along untouched. It's the answer to a want the plain arrow can't satisfy: "show me this and keep a copy."

npm run build | tee build.log
# The build scrolls past as usual — AND lands in build.log

npm test 2>&1 | tee test.log     # errors included, still watching live

With a plain > you trade the live view for the file; tee refuses the trade. That makes it the receipt habit for anything long-running — let an agent's build talk to the screen while tee keeps the transcript, and "what did it actually say?" always has an answer. (tee -a appends instead of overwriting, the same courtesy >> extends.)

Try It: Catch the Red Text

Redirection sends output into a file. The pipe — | — sends it into another command. Whatever the left command prints becomes the right command's input, no temporary file needed. This one character is the reason terminal users never left.

ls ~/Downloads | wc -l        # How many things are in Downloads?
47

history | tail -5             # The last 5 commands you ran

cat server.log | grep "ERROR" | wc -l   # How many errors in the log?
12

Two small things in there. history prints the shell's own record of what you've typed — it keeps one, whether or not you asked, and History Superpowers puts that record to work. And tail -5 is shorthand for tail -n 5: for head and tail, a bare dash-and-number is a line count. Not every dash-and-number is: the 9 in kill -9 is a signal number, which Stopping Things unpacks.

Read a pipeline left to right, like an assembly line: the text flows through each station and comes out transformed. Here's the last example as a picture:

This is the Unix philosophy, and it's older than most programming languages you know: "Write programs that do one thing and do it well," as Doug McIlroy — the inventor of the pipe — put it. grep only searches. wc only counts. sort only sorts. None of them is impressive alone — but because they all speak plain text, any of them can feed any other, and a handful of tiny tools becomes thousands of combinations.

A server just crashed and the log is 10,000 lines long. Nobody scrolls that. grep prints only the lines that match a pattern — it's the terminal's search box, and probably the most-used tool in this course.

That 10,000-line log is a log file — a plain text file a program keeps appending to as it works, one line per event, oldest at the top. Most programs tag each line with a severity word: DEBUG for chatter, INFO for normal, WARN and ERROR for trouble. That convention is why searching for the bare word ERROR works at all.

grep "ERROR" server.log          # Lines containing ERROR
2026-07-11 14:02:11 ERROR db connection refused
2026-07-11 14:02:15 ERROR retry limit reached

grep -r "TODO" src/              # Search every file under src/
src/app.js:14:  // TODO: handle empty cart
src/utils.js:3: // TODO: remove this hack

Both patterns above are plain words, which is why nothing surprising happened. The moment you reach for a wildcard, though, you've changed languages. grep doesn't use globs. It uses regular expressions — a second, older pattern language that looks deceptively similar and means different things. Here * means "zero or more of whatever came just before it", . matches any single character, and ^ and $ anchor a match to the start and end of a line. The trap isn't hypothetical: ERR* as a glob means "starts with ERR", but as a regular expression it means "ER followed by any number of Rs" — so it matches ER anywhere in any line, and quietly hands you the wrong answer.

The glob column is the one you drilled in Wildcards, and it still governs every filename you type. The regex column governs what's inside the quotes you hand to grep, and later to sed and awk. Same characters, different room.

Five flags cover 95% of real-world grep:

And because grep reads standard input, it slots into any pipeline as a filter. This is the pattern you'll type every single day:

history | grep "cd"              # Every cd you've ever run
tail -50 server.log | grep -i "error"   # Only recent errors
grep "ERROR" server.log | grep -v "retry"  # Errors, minus the noisy ones

Try It: Find the Crash

grep finds lines. These four tools reshape them: count them, order them, de-duplicate them, and slice out columns. Individually they're almost boring — together they answer real questions, like "who's hammering my website?"

wc -l server.log        # Count lines (-w words, -c bytes)
843 server.log

sort names.txt          # Alphabetical order (-n numeric, -r reversed)

uniq names.txt          # Collapse REPEATED ADJACENT lines into one

cut -d',' -f2 users.csv # Slice column 2, using ',' as the delimiter

That last line hides a rule: some flags take a value. -d',' is one flag — d for delimiter — with its value jammed straight onto the letter, and -f2 is f for field, value 2. Other commands want a space between the two, as in -n 3, and many take either. So -f2 is not two clustered flags the way ls -la is — where the letter ends and its value begins is each command's own decision, and man cut is what tells you.

Try It: Count Before You Fix

Now the payoff. Your web server writes one line per visit to access.log, and you want to know your top visitors. This is the most famous pipeline in Unix history, and we'll build it one stage at a time — exactly the way you should build every pipeline.

head -4 access.log
203.0.113.9 GET /home
198.51.100.4 GET /pricing
203.0.113.9 GET /docs
192.0.2.55 GET /home

Two things to read before you start slicing. The number at the front is the visitor's IP address — each machine on a network has one, and What Is localhost? takes it apart. And /home and /pricing are URL paths — the part after the site's address — not folders on this machine. Same slashes, different tree.

cut -d' ' -f1 access.log
203.0.113.9
198.51.100.4
203.0.113.9
192.0.2.55
...

# -d' ' = columns are separated by spaces; -f1 = give me field 1

cut -d' ' -f1 access.log | sort
192.0.2.55
198.51.100.4
198.51.100.4
203.0.113.9
203.0.113.9
203.0.113.9
...

cut -d' ' -f1 access.log | sort | uniq -c
   1 192.0.2.55
   2 198.51.100.4
   3 203.0.113.9
...

# -c = count: each collapsed group carries a tally of how many lines it stood for.
# (Not grep's -c, which prints one total and no lines at all.)

cut -d' ' -f1 access.log | sort | uniq -c | sort -n
   1 192.0.2.55
   2 198.51.100.4
   3 203.0.113.9

# Biggest number last — your top visitor is 203.0.113.9

Try It: Build a Pipeline

grep searches inside files. But sometimes the question is "where is that file?" — a config you know exists, every Markdown file in a project, that one script you wrote last month. find walks an entire directory tree and prints every path that matches your criteria.

find . -name '*.md'            # Every Markdown file below here
./README.md
./docs/setup.md
./docs/notes/ideas.md

find . -name '*.md' -type f    # -type f: files only
find . -type d -name 'test*'   # -type d: directories only
find ~ -name '.zshrc'          # Start the search from your home folder

Keep the two search tools straight — they're a team, not rivals:

And naturally, they compose. Find the files by name, then grep inside exactly those:

find . -name '*.js' | xargs grep -n "TODO"
./src/app.js:14:  // TODO: handle empty cart
./src/utils.js:3: // TODO: remove this hack

# (For a whole tree, grep -rn "TODO" . is the simpler everyday version.)

xargs is there because grep wants filenames as arguments, not on standard input. Pipe a list of paths straight into grep and it dutifully searches the text of those paths instead of the files they name — a pipeline that runs, returns nothing, and looks like an answer. xargs collects the lines arriving on standard input and lays them out as arguments, which is the shape grep was waiting for. Reach for it when you want to narrow the file set first — by name, type or depth — and reach for grep -rn when you want everything under a folder.

Try It: Hunt Down Every TODO

Notice what all of these have in common: they find and count — none of them changes a single character. That's deliberate, and it's why they're safe to experiment with. When you're ready to make text different — swap a word across a file, drop every DEBUG line, pull one column out of a table — that's sed and awk, waiting in Text Surgery.

Permissions & Environment: How the Machine Decides

You met ls -l back in Moving Around and politely ignored the cryptic string at the start of each line. Time to decode it — those 10 characters are the entire permission system in miniature.

ls -l
-rw-r--r--  1 vibe  staff   214 Jul 10 09:12 notes.txt
-rwxr-xr-x  1 vibe  staff   512 Jul 10 09:30 deploy.sh
drwxr-xr-x  4 vibe  staff  4096 Jul  9 18:02 projects

Before those ten characters, the two names in the middle: they decide who the rules apply to. vibe is the owner, and staff is the group — a named set of accounts the system can grant permission to all at once. On a shared server that's your team; on your own laptop it's usually staff or a group named after you with nobody else in it, which is why the group's rules rarely bite until someone else is on the machine. id -gn — g for group, n for the name rather than the number — prints the name of yours. Owners can be reassigned: chown ("change owner") hands a file to a different account, and it's a root-only move you'll mostly meet on servers and around Docker, where files created inside a container come out owned by somebody who isn't you. Recognize it when an agent proposes it; on your own laptop you'll almost never type it.

Take -rwxr-xr-x apart and it's four pieces: one type character, then three groups of three — the same three questions asked of three audiences:

So -rwxr-xr-x reads as: a regular file; the owner can read, write, and run it; the group can read and run it; everyone else can read and run it. And -rw-r--r-- is a typical document: only the owner can edit, everyone can read, nobody can execute. projects opens with a d because it's a directory; the third type character you'll meet is l, a symbolic link (Links & Where Things Live).

Here's the classic novice moment: you save a script, try to run it, and the terminal snaps back Permission denied. Nothing is broken. The file simply doesn't have its x bit yet — files are never executable by default. The .sh on the end isn't what runs it either; that's a convention for humans and editors (Looking Inside Files), and the file would run just as well named backup. chmod ("change mode") flips the switch that does.

./backup.sh
bash: ./backup.sh: Permission denied

ls -l backup.sh
-rw-r--r--  1 vibe  staff  164 Jul 11 10:04 backup.sh   # no x anywhere

chmod +x backup.sh          # Grant execute permission
ls -l backup.sh
-rwxr-xr-x  1 vibe  staff  164 Jul 11 10:04 backup.sh   # x appears

./backup.sh                 # Now it runs
Backing up projects/ ... done.

+x is a small grammar rather than a magic word. + adds a permission and - removes it, and you can put an audience in front: u for you, g for your group, o for everyone else, a for all three. A bare +x means a+x, which is why the line above became -rwxr-xr-x and not just -rwxr--r--. When you only want it for yourself, say so: chmod u+x backup.sh.

And the leading ./ isn't decoration. Typed bare, backup.sh sends the shell hunting through the short list of folders it keeps for programs — Environment Variables names that list — and the folder you're standing in is deliberately not on it, so nothing dropped into your current directory can impersonate a real command. ./ means "the file right here": you saying you meant this one.

You'll also see chmod used with numbers — chmod 755, chmod 644 — in every tutorial and AI suggestion. Each digit is one audience (user, group, other), built from r=4, w=2, x=1. But you don't need the arithmetic — in practice there are exactly two recipes worth knowing:

Try It: The Script Won't Run

Some things your everyday account simply may not touch: installing system-wide software, editing files outside your home folder, managing services. For those, there's sudo — "superuser do." It runs one command as root, the administrator account that no rule applies to.

apt install htop                 # Linux: htop is a live view of what's running
E: Permission denied             # E: is apt marking its own error, the way bash: marks bash's

sudo apt install htop            # Same command, run as root
[sudo] password for vibe:        # Type your password — nothing appears. Normal!
Setting up htop ... done.

Two things to know before you ever need it. First, the password prompt shows nothing while you type — no dots, no asterisks. Every beginner assumes their keyboard broke; it's just a privacy habit from 1970 that stuck. Second, you need sudo far less than the internet implies: everything inside your home folder is already yours, and macOS users installing via Homebrew usually don't need it at all. If a command fails inside ~, the answer is almost never sudo — it's a wrong path or a missing +x.

Every command you run inherits a set of named values called the environment: your username, your home folder, your preferred editor, and — most importantly — where the shell should look for commands. You've been using them all along without noticing; cd with no arguments reads $HOME to know where to take you.

echo $HOME                # $NAME reads a variable
/home/vibe

echo $USER
vibe

env | head -4             # env lists everything currently set
HOME=/home/vibe
USER=vibe
PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash

export EDITOR=nano        # Set one, and hand it down to what this shell starts
echo $EDITOR
nano

The $ is what does the work: write $EDITOR and the shell swaps in the value before the command ever sees it, which is why echo $SHELL prints a path and not the word SHELL. Note the asymmetry — you write export EDITOR=nano with no dollar sign and read it back with one. And export is the word that decides who else can see it: a bare EDITOR=nano stays in this shell, while export EDITOR=nano hands the setting down to every program the shell launches from here on. Either way it evaporates when you close the terminal — making it stick is the next section's job.

$HOME and the ~ from Moving Around name the same folder but aren't the same kind of thing. ~ is shell shorthand, expanded only at the start of a word and never inside quotes; $HOME is a real variable and expands anywhere a $ does. So cp report.md "~/backups/" never reaches your home folder: the quotes turn the ~ into an ordinary character, and cp goes looking for a folder literally named ~ in the directory you're standing in. Write "$HOME/backups/" and it lands where you meant. (This is one of the few places the playground is kinder than a real shell: its paths expand ~ either way, so the quoted version quietly works there and bites you on your own machine.)

The variable that explains a thousand error messages is PATH: a colon-separated list of directories — /usr/bin, /usr/local/bin and friends, where bin is short for binaries, the programs themselves. When you type python, the shell walks that list in order, looking in each directory for an executable file with that name. First match wins; no match anywhere means the infamous:

echo $PATH
/usr/local/bin:/usr/bin:/bin

pyhton --version
bash: pyhton: command not found      # 1. Or it's just a typo...

python --version
bash: python: command not found      # 2. ...or it's not installed...
                                     # 3. ...or it's installed somewhere
                                     #    that isn't on PATH.

which ls                             # 'which' shows where a command lives
/bin/ls
which python                         # Silence/nothing = not on PATH

--version earns its place there: it prints the version number and exits without doing anything, so it's the harmless way to ask whether a program exists at all. which answers the other PATH question — when two copies of a tool are installed, the one it prints is the one you're running. Because the shell stops at the first match, a copy in /usr/local/bin quietly shadows the system's in /usr/bin, which is how you end up on a version you didn't mean to run.

Try It: command not found

Everything you've customized so far — exported variables, the aliases you're about to meet — dies with the terminal window. The fix is the shell config file: a plain text file of commands your shell runs automatically every time it starts. It's ~/.bashrc if your shell is bash, and ~/.zshrc for zsh — the macOS default. (A hidden dotfile, which is why ls -a from Moving Around is how you spot it.)

The customization you'll use most is the alias — a personal shorthand for a longer command:

alias ll='ls -lh'         # Define it — -l long listing, -h human-readable sizes
ll                        # Use it — the shell expands ll to ls -lh
-rw-r--r--  1 vibe staff 1.2K Jul 11 09:14 notes.txt
-rwxr-xr-x  1 vibe staff  512 Jul 10 09:30 deploy.sh

alias                     # List every alias currently defined

That 1.2K is -h doing its job: the raw byte counts Moving Around showed you, rounded into units you can read at a glance. Typed at the prompt, an alias lasts only for that session — put it in your config file to keep it forever. Here's a battle-tested starter set to paste into ~/.zshrc (or ~/.bashrc):

# --- TerminalVibes starter aliases ---
alias ll='ls -lh'               # Detailed listing, human-readable sizes
alias la='ls -lah'              # ...including hidden dotfiles
alias ..='cd ..'                # Hop up one level
alias ...='cd ../..'            # Hop up two
alias gs='git status'           # You will type this constantly
alias grep='grep --color=auto'  # Highlight what matched

One of those needs a word. Git is the version-control tool that records snapshots of a project as you work — a whole subject of its own, and deliberately not this course's (Keep Learning). You're pasting gs now because it's the first command anyone reaches for the moment they meet git; nothing between here and the end depends on understanding it.

The other line you'll end up pasting into this file is the one installers keep asking for. When a tool lands in a folder your shell doesn't search, "add it to your PATH" means exactly one line here:

export PATH="$PATH:$HOME/.local/bin"
# Read it right to left: take PATH's current value, add one folder, save it back

The $PATH on the right-hand side is the read/write asymmetry from Environment Variables doing real work: it expands to the old list first, so you're appending, not replacing. Drop it — export PATH="$HOME/.local/bin" — and every command on the machine goes command not found at once, because you just told the shell to search one folder and nothing else. No lasting harm done (the broken value dies with the terminal window, and the file isn't re-read until a new shell starts), but it's a memorable minute.

One last piece: the config file only runs at startup, so a freshly edited file changes nothing in your current terminal. Either open a new window — or reload it in place with source:

source ~/.zshrc     # Re-run the config file right here, right now
# (bash users: source ~/.bashrc)

source is doing something more general than reloading a config, and it's worth seeing what. Run a file of commands the ordinary way — ./deploy.sh, or bash deploy.sh — and you start a child shell: a fresh copy of the shell that reads the lines, does them, and exits, taking its variables and its cd with it. Nothing it changed survives. source does the opposite, running the lines in the shell you're sitting in, so everything sticks. It's also why a script full of cd never seems to move you anywhere.

One more place changes hide: ~/.zshrc and ~/.bashrc are read every time you open a terminal window, while ~/.zprofile and ~/.bash_profile are read only at login. If an edit stubbornly refuses to take, you probably edited the other one.

Try It: Make Your Shortcuts

Scripts & Automation: Teach the Machine Your Routine

That's the idea. Everything you've typed at the prompt this entire course could be pasted into a file and replayed. Let's build one — a tiny backup script — and hit every ingredient along the way.

#!/usr/bin/env bash
# Back up the notes folder with today's date in the name.

BACKUP_NAME="notes-backup-$(date +%F)"

mkdir -p backups
cp -r notes "backups/$BACKUP_NAME"
echo "Backed up notes to backups/$BACKUP_NAME"

Three new things in eight lines:

Now make it runnable. Two steps, both from chmod: give the file execute permission, then run it with the explicit ./ path. The .sh on the end is convention for humans and editors — the execute bit and that first line are what actually run it.

chmod +x backup.sh
./backup.sh
# Backed up notes to backups/notes-backup-2026-07-12

The ./ is there for the reason that section gave: a bare backup.sh sends the shell hunting through PATH, and this folder deliberately isn't on it. Running it this way also starts a child shell, so the script's variables and any cd inside it are gone the moment it exits — exactly the distinction Your Shell Config drew.

Arguments: $1 makes it reusable

Inside a script, $1 is the first argument the script was handed — the words after its name (Getting Help), numbered in the order they arrived, so $2 is the second. One change turns our notes-only script into a back-up-anything script:

#!/usr/bin/env bash
# Usage: ./backup.sh <folder>

TARGET="$1"
BACKUP_NAME="$TARGET-backup-$(date +%F)"

mkdir -p backups
cp -r "$TARGET" "backups/$BACKUP_NAME"
echo "Backed up $TARGET to backups/$BACKUP_NAME"

./backup.sh notes
# Backed up notes to backups/notes-backup-2026-07-12

./backup.sh recipes
# Backed up recipes to backups/recipes-backup-2026-07-12

How agents deliver a file: the here-doc

Watch a coding agent create a file and you'll see one shape over and over — a whole file, delivered in a single command:

cat <<'EOF' > backup.sh
#!/usr/bin/env bash
mkdir -p backups
cp -r notes "backups/notes-$(date +%F)"
EOF

Read the first line in three parts. cat you know. <<'EOF' is a here-document: "feed the lines that follow straight in as input, until a line that says exactly EOF." And > backup.sh is the redirection from Text & Pipes, catching all of it in a file. The delimiter is any word you like — EOF ("end of file") is convention, not a keyword. The quotes around it are the single-quote rule from Paths in a new costume: quoted, every $ between the markers travels into the file literally — which is what you want when the script's own $(date +%F) should run later, not now. Unquoted, the shell expands them all before the file is even written. One habit to take from this: the lines between the markers are the file — audit them exactly the way you'd audit the script they're about to become. (The playground doesn't speak here-docs; this one is for reading agent transcripts, and for your real machine.)

Try It: Automate the Backup

Now make it reusable. A hard-coded path backs up one folder; $1 backs up whatever you name. Same audit habit applies — read the script before you run it.

Try It: One Script, Any Folder

Every command, when it finishes, hands the shell a number called its exit code: 0 means success, and anything else (1 to 255) means some flavor of failure. Which number it picks is each command's own business and means nothing outside that command, so there's no master table to go hunting for — only zero-or-not-zero travels between commands. You never see it unless you ask — the special variable $? holds the exit code of the last command:

ls notes
# recipes.md  todo.md
echo $?
# 0            <- found it, success

ls no-such-folder
# ls: cannot access 'no-such-folder': No such file or directory
echo $?
# 2            <- non-zero: it failed, and it said so

On its own that's a curiosity. It earns its keep with the three chaining operators, which decide whether the next command runs based on the last one's exit code:

true && echo "ran"        # ran        (true exits 0)
false && echo "ran"       #            (nothing - && skips after failure)
true || echo "ran"        #            (nothing - || skips after success)
false || echo "ran"       # ran

# The pattern you'll use every day:
npm test && npm run deploy
# tests pass  -> deploy runs
# tests fail  -> deploy never happens

# And the three-operator shape, read left to right:
npm test && npm run deploy || echo "something failed"

true and false in the first four lines are real little programs whose entire job is to exit 0 and 1 — which is what makes that truth table runnable rather than illustrative. The last line has a catch. The chain runs left to right and neither operator outranks the other, so the || is not paired off against the && — it fires whenever the command immediately before it failed. Tests pass, deploy fails, and the message prints anyway. Useful here, but it is not the one-branch-or-the-other shape it looks like. (Package Managers covers what npm run deploy is running.)

One number decides which branch runs — the same mechanism behind every CI pipeline (continuous integration: servers that build and test your code for you, automatically).

The classic horror story: ; where && belonged

Why does the choice of connector matter so much? Because of lines like this one, which has genuinely destroyed home directories. The target sits in /tmp, the machine's shared scratch space (Paths), so emptying a folder inside it is a perfectly ordinary thing to want:

# THE TRAP - a semicolon runs the rm NO MATTER WHAT:
cd /tmp/build ; rm -rf *
# If /tmp/build doesn't exist, cd FAILS... and rm -rf * runs
# anyway - in whatever directory you were standing in. Maybe ~.

# THE SAFE VERSION - && only deletes if the cd succeeded:
cd /tmp/build && rm -rf *
# cd fails -> the chain stops -> nothing is deleted.

And here's why this little number matters beyond one-liners: the entire automated world runs on exit codes. CI pipelines decide pass-or-fail by the exit code of your test command — and GitHub, which stores projects and runs those tests every time someone sends up new code, draws its green checkmark to mean "everything exited 0." Coding agents watch exit codes the same way: run a command, read $?, and decide whether to continue, retry, or fix. When your agent says "the tests failed, let me look" — it didn't read your mind. It read an exit code. Scripts join the same game: a script's own exit code is that of its last command, so scripts can chain scripts, and the whole tower stands on one convention. Zero means go.

Try It: Deploy Only on Green

Text Surgery: Find, Change, Extract

Every editor has find-and-replace. sed is find-and-replace unplugged from the editor — it works on anything that flows: files, pipes, command output. One tiny script does it all, and it reads like a sentence once you know the grammar:

cat menu.txt
mango smoothie — mango, ice, lime

sed 's/mango/kiwi/' menu.txt      # replace the FIRST match on each line
kiwi smoothie — mango, ice, lime

sed 's/mango/kiwi/g' menu.txt     # g = every match on the line
kiwi smoothie — kiwi, ice, lime

Read s/mango/kiwi/g in four beats: s means substitute; mango is find this; kiwi is replace with this; g means every match on the line, not just the first. That find half is a regular expression rather than a plain string, so ., *, ^ and $ carry the meanings they had in Searching Text — a dot matches any character, even where you meant a literal one. Two more pieces complete the grammar: I ignores case, and the slashes are just delimiters — any character works, which saves you from escaping paths:

sed 's|/usr/local|/opt|' paths.txt     # | instead of / — no escaping
sed 's/error/[&]/I' app.log            # & = whatever matched; I = any case
[ERROR] payment timeout                # "error", "Error", "ERROR" all wrapped

That | is doing sed's job, not the shell's — inside the quotes it's a delimiter, and the same character outside them is the pipe from Text & Pipes. The single quotes are the whole difference: they hand sed its script as one untouched word (Paths), which is why every sed script in this part wears them.

Try It: Rebrand the Menu

Substitution is only one of sed's commands. Picture your file as a film strip: every line passes through sed, one frame at a time, and a command decides its fate — keep, drop, or print. An address in front of the command selects which frames it applies to:

sed '/DEBUG/d' app.log        # drop every line matching DEBUG
sed '3d' notes.txt            # drop line 3
sed '2,5d' notes.txt          # drop lines 2 through 5
sed '$d' notes.txt            # drop the last line

Those four are most of the address vocabulary, and two of them are worth a second look. /DEBUG/ is a regular expression tried against every line, not a plain word — the same rules as the find half of s///. And $ here is sed's name for the last line: an address, not a variable, with nothing to do with the $NAME expansion from Environment Variables. awk hands the same character a third job in Columns & awk.

The mirror image of dropping is printing only what you ask for. That's the p command paired with -n, which silences sed's default echo. It's the precision tool for "show me lines 40 through 55 of that huge log" — no pager, no scrolling:

sed -n '40,55p' server.log     # just lines 40–55
sed -n '/ERROR/p' server.log   # only ERROR lines (like grep!)
sed -n '/start/,/stop/p' run.log   # from a /start/ match to a /stop/ match

Addresses compose with any command — '2s/beta/B/' substitutes on line 2 only, '/alpha/s/a/A/' substitutes only on lines matching alpha. One grammar, every combination. That's the Unix philosophy again, folded inside a single tool.

Try It: Silence the Debug Noise

Everything so far printed to the screen or a new file. But the command agents actually propose is usually sed -i — edit the file in place. Same substitution, except now it rewrites the real file, silently, with no preview and no undo. -i was the letter that stopped and asked before overwriting back in Copying; here it means the opposite of careful, which is exactly what Getting Help meant by flag letters belonging to their command. It's also the one sed flag worth carrying into Terminal for the AI Era, where auditing becomes a routine.

sed -i.bak 's/http:/https:/g' config.yml
                    # config.yml      — rewritten
                    # config.yml.bak  — the original, untouched

diff config.yml.bak config.yml   # exactly what changed, nothing else
mv config.yml.bak config.yml     # instant rollback if it went wrong

The suffix goes directly after the flag — -i.bak, no space — and sed saves each original as file.bak before rewriting. It costs nothing, it works on many files at once (sed -i.bak 's/<old>/<new>/' *.yml backs up every one), and it turns "I hope that was right" into something you can check. That's the diff in the block above: hand it two files and it prints only the lines where they disagree. When an agent proposes a bare -i, don't approve or reject — edit the command and add the .bak.

macOS enforces the house rule anyway. Mac and Linux carry different lineages of the same veteran tools — BSD's on the Mac, GNU's on Linux — and BSD sed insists on that suffix: leave it off and the command fails with an error pointing nowhere near the real problem, while GNU sed takes the bare -i and keeps no copy at all. ps, ls and du split the same two ways, which is why a command that worked on a colleague's machine sometimes doesn't on yours.

Try It: The Agent's Mass Edit

A lot of terminal output is secretly a table: log lines, CSV exports, process listings. awk splits every line into numbered fields and prints the ones you name — $1 is the first column, $2 the second, $0 the whole line:

awk '{print $2}' table.txt          # second column (splits on spaces)
awk -F, '{print $1, $3}' data.csv    # -F, = split on commas; comma joins with a space
awk '/error/ {print $1}' app.log     # /pattern/ runs the action on matching lines only

The braces are awk's action block — the work it does on every line that reaches it, with the /pattern/ guard outside and in front. The $1 inside belongs to awk, not the shell: it has nothing to do with the numbered script arguments in Your First Script, and that collision is why every awk program here sits in single quotes. Swap them for double quotes and the shell empties $1 before awk ever sees it: {print $1} arrives as {print }, which awk reads as "print the whole line" and obeys without complaint — the wrong answer, delivered confidently. Ask for two columns and it's a syntax error instead. Neither one mentions quotes.

You already know cut from Text & Pipes — so which one? Honest answer: cut when a single character separates every field — a comma in a CSV, a colon or a tab elsewhere — and awk when the spacing is ragged. awk's default split treats any run of spaces as one separator, which is exactly what column-aligned output needs — cut would see every space as its own empty field and hand you garbage. When you meet process listings in Everything Is a Process, awk is the tool that reads them.

Try It: Pull the Column

Your text toolbox is complete: grep finds, sed changes, awk extracts — and pipes chain them into anything. Every one of them previews to the screen before it touches a file, which means every one of them rewards the habit this course keeps drilling: read first, run second.

Processes & Ports: When Things Won't Stop

Every running program on your machine — the dev server, your editor, the shell you're typing into, the agent itself — is a process: one copy of some code, loaded into memory and kept alive by the operating system. Open three terminal windows and you have three shell processes, each with its own idea of where it's standing. Each one gets a PID — short for process ID — the moment it starts, a number unique on this machine for as long as it lives. That number is the handle you use to do anything to it.

ps on its own lists only the processes attached to this terminal — usually two or three, and never the dev server you're hunting. Add aux and you get the whole machine:

ps aux
USER       PID %CPU %MEM START   COMMAND
vibe      1024  0.0  0.1 09:10   bash
vibe       400  0.4  1.8 08:41   node server.js
vibe       437 97.4  0.6 09:07   spinner.sh --forever

The three letters earn their place: a widens the list to every user's processes, u adds the human-readable columns you're about to read, and x includes the ones with no terminal attached — which is precisely where background servers hide. (They carry no dash: ps takes its options in an older style that predates the convention, the same reason tar cf works without one.) Your real output is wider than this too — macOS and Linux both add memory sizes, a terminal name and a state column. Ignore those; the ones that matter are here.

USER is the account that owns the process — vibe is you, which is why you can stop your own dev server and get Operation not permitted on one of the system's. PID is the number you'll pass to kill. %CPU is how hard it's working, measured against one core, and your machine has several: separate workers that genuinely run at the same time, so a process using three of them honestly reads 340%. A runaway of yours sits near 100, and your fans tell you before ps does. %MEM is the share of the machine's memory it's holding, the column to check when everything goes sluggish rather than hot.

START is the wall-clock time it launched, the one column that separates the server you started a minute ago from yesterday's, still running. COMMAND is what it actually is — though that's the interpreter's name, not your project's: a JavaScript server shows up as node, a Python one as python, and that's what you grep for. Notice bash in that list too: the shell you're typing into is just another process, no more special than the rest.

kill has a violent name and a polite default. Plain kill PID sends SIGTERM — a signal, which is a short fixed message the operating system delivers to a running process from outside, nothing to do with whatever the program normally reads. They come in a small vocabulary and all share a prefix: SIG for signal, then what it asks for, so SIGTERM is "terminate" — please finish up and stop. The program gets to react: save its work, close its files, remove its lock, and exit cleanly. It's a letter, not a bullet.

kill 437                 # SIGTERM, signal 15 — "please stop when you can"
(no response — spinner.sh --forever is still running)

kill -9 437              # SIGKILL, signal 9 — the floor opens, no cleanup
[killed] spinner.sh --forever (PID 437)