Copying, Moving, Deleting Safely

In one line

cp, mv, and rm look simple, but rm in particular has no undo, no trash can, and no confirmation by default — the habits in this topic exist specifically to prevent the classic 'I just deleted the wrong thing' disaster.

0/7 · 0%

Think of it like this

Real-life example: rm is like a paper shredder, not a trash can — there is no 'Recycle Bin' to fish something back out of by default. Once shredded, it's gone; this single fact should shape how carefully you use rm for the rest of your career.

Key ideas

01
cp <source> <dest> copies a file (add -r to copy an entire directory recursively — plain cp refuses to copy directories on its own, a deliberate safety check). mv <source> <dest> MOVES (or renames, which is really just 'moving to a new name in the same place') a file — unlike cp, there's no need for -r since moving a directory doesn't require duplicating its contents.
02
rm <file> deletes a file permanently, no confirmation, no trash. rm -r <directory> deletes an entire directory and everything inside it, recursively. rm -rf <directory> adds -f (force — suppresses any warnings/prompts) — this exact three-letter combination, rm -rf, is infamous precisely because it's fast, silent, and irreversible all at once.
03
mkdir <name> creates a new, empty directory. mkdir -p a/b/c creates ALL the intermediate directories needed in one shot (creating a, then a/b, then a/b/c) even if none of them exist yet — without -p, mkdir a/b/c fails outright if a doesn't already exist.
04
A genuinely good habit: before any rm -r or rm -rf, run the equivalent ls on the exact same path first to see precisely what you're about to delete — the same 'preview before you act' discipline Docker's own course taught for wildcard deletions, because the underlying risk is identical.

In your stack

→
Cleaning up a Maven/Gradle project's build output is a common real use: rm -rf target/ (Maven) or rm -rf build/ (Gradle) wipes the build directory entirely so the next build starts completely fresh — genuinely useful, but exactly the kind of command worth double-checking you're in the RIGHT directory before running, since target/ and build/ are common folder names that could exist elsewhere too.

Code & diagrams

copy-move-delete.shmarkdown

Practice on a throwaway directory — create it fresh so nothing here can hurt anything real.

# Set up a safe playground
mkdir -p ~/scratch/testdir
cd ~/scratch/testdir
touch a.txt b.txt

# Copy a file
cp a.txt a-copy.txt

# Copy an entire directory (needs -r)
mkdir subdir
cp -r subdir subdir-copy

# Move/rename a file
mv b.txt b-renamed.txt

# ALWAYS preview before deleting
ls subdir-copy
rm -r subdir-copy

# mkdir -p creates every missing intermediate directory
mkdir -p deep/nested/path
ls -R deep

Explain it without notes

Why does plain cp refuse to copy a directory without the -r flag, while mv doesn't need any special flag to move one?

A teammate ran rm -rf on the wrong directory by accident. What are their realistic recovery options?

Practice

In a throwaway directory, create a small nested folder structure with mkdir -p, copy the whole thing with cp -r, then delete the copy (not the original) with rm -r after confirming with ls first.

Try running cp on a directory WITHOUT -r and read the exact error message Linux gives you — it's worth seeing this refusal happen once on purpose.

Trade-offs

↔
rm -rf's speed and silence are exactly what makes it useful for legitimate bulk cleanup (deleting a build directory, clearing a cache) — the same properties that make it dangerous are what make it efficient; the mitigation is discipline (preview first), not avoiding the command entirely.

Done when you can

I know rm has no trash can — deletions are permanent by default.
I always preview a path with ls before running rm -r or rm -rf on it.
I understand why cp needs -r for directories but mv does not.

Command Palette