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