Module 1.4 — Copy, move, rename, and delete

Once files exist, reorganize them with cp, mv, and rm. There is usually no undo — practice inside a folder you can delete entirely.

By the end you should be able to: copy files and trees (cp -r); rename vs move with mv; delete carefully; follow create → copy → edit → move → delete-last.

Scroll Core ideas → worked examples → Quiz. Plan on roughly 55–60 minutes.

Core ideas — copying, moving, and removing with care

So far you have learned to look around and to write text. This module teaches the three commands that reorganise what is already there: cp (copy), mv (move or rename), and rm (remove). Together they let you back things up, tidy folders, and clear clutter. They also introduce a theme that will stay with you for the rest of your terminal life: some commands cannot be undone, so the order in which you do things, and the habit of looking before acting, become part of the skill.

Our setting is still Sam's coastal observation project, tidewatch, inside the sandbox ~/cli-practice. The tree is the familiar one:

tidewatch/
  notes/
  drafts/
  scripts/
  archive/
  data/
    raw/
    processed/

---

Why these three belong together

Think about what you do with paper documents on a desk. You photocopy a page before scribbling on it. You carry a page from one tray to another, or you cross out its title and write a better one. And eventually you put some pages in the shredder. Those are three very different acts, and the three commands match them one-to-one: copy leaves the original in place and adds a second page; move carries the same page elsewhere or changes its label; remove destroys it.

The difference that matters most is how reversible each is. A copy is easy to throw away. A move is usually easy to reverse by moving back. A removal is not reversible at all. Keeping that ladder in mind — safe, mostly safe, permanent — is the best protection you have.

---

cp: copy a file

The basic shape is cp SOURCE DESTINATION. Read it as "make a copy of SOURCE and call it DESTINATION."

cd ~/cli-practice/tidewatch
cp notes/tides.txt notes/tides_backup.txt
ls notes

The listing now shows both tides.txt and tides_backup.txt. The original did not move and did not change; there are simply two files with the same contents. If the destination is a directory rather than a new file name, the copy goes inside it and keeps its original name:

cp notes/tides.txt archive/

Now archive/tides.txt exists as well. The trailing slash on archive/ is not required, but it is a helpful visual reminder that you mean "into this folder."

---

Copies are independent

Once a copy exists, it is a separate file. It is not a shortcut, a link, or a live mirror. Changing one has no effect on the other.

echo "High tide at 12:30" >> notes/tides.txt
cat notes/tides_backup.txt

The backup does not show the new line, because it was cut off from the original at the moment of copying. This is exactly what makes cp such a good safety net: copy a file before a risky edit, work on the original, and if the edit goes wrong you still have the earlier version sitting beside it.

The flip side is that independence means drift. If you keep three copies of one file and later fix a mistake in only one of them, the others still hold the mistake. Give copies clear names (tides_backup.txt, not copy2.txt) and delete the ones you no longer need.

---

The silent overwrite

Here is the first danger. If the destination file already exists, cp replaces it, quietly:

cp notes/plan.txt notes/tides.txt

This overwrites tides.txt with the contents of plan.txt. There is no question, no warning, and no backup of the lost version. It is the same kind of surprise you met with the single > arrow in the previous module.

You can ask the command to check with you first by adding the interactive option:

cp -i notes/plan.txt notes/tides.txt

Now cp stops and asks overwrite notes/tides.txt?. Typing y proceeds; anything else cancels. While you are learning, using -i is a cheap way to turn a silent mistake into a visible question.

---

cp -r: copying a whole folder

A folder is not a single file; it is a container with contents. If you try to copy one with plain cp, the command refuses:

cp drafts drafts_copy

The message says that drafts is a directory and was not copied. To copy a folder and everything inside it, add -r (for recursive, meaning "go down through every level"):

cp -r drafts drafts_copy

Now drafts_copy/ exists with the same files and subfolders as drafts/. As with single files, the two folders are independent afterwards.

---

Where does the folder copy land?

A subtle but important detail: the result of cp -r depends on whether the destination already exists.

• If drafts_copy does not exist, it is created and becomes the copy.
• If drafts_copy does exist as a folder, the copy is placed inside it, giving drafts_copy/drafts/.

This catches people out. Run the same command twice and the second run builds a nested folder you did not intend. A good habit is to run ls on the destination first and to expect one outcome or the other before you press Enter.

---

mv: one command, two meanings

mv has the same shape, mv SOURCE DESTINATION, but it does not leave the original behind. What it does depends on what the destination is.

Rename. If the destination is a new name in the same place, the file is relabelled:

mv notes/tides_backup.txt notes/tides_monday.txt

The file is still in notes/; only its name changed. No copy was made.

Move. If the destination is an existing directory, the file is carried into it:

mv notes/tides_monday.txt archive/

Now tides_monday.txt lives in archive/ and no longer in notes/. You can combine both effects by giving a folder and a new name: mv notes/plan.txt archive/old_plan.txt moves and renames in one step.

If that felt abrupt, notice the single clue that tells you which is which: is the destination an existing folder? If yes, mv places the file inside it. If no, mv treats the destination as the file's new name.

---

mv on folders, and its own silent overwrite

Unlike cp, mv needs no extra option to handle folders. mv drafts old_drafts renames the folder, and mv old_drafts archive/ carries the whole thing, contents included, into archive/.

Like cp, though, mv will overwrite an existing destination file without asking. If archive/tides.txt is already there and you run mv notes/tides.txt archive/, the older archived file is replaced. The cautious version is again mv -i, which asks first. Before moving anything into a busy folder, a quick ls archive shows what is already present.

---

rm: remove a file, permanently

rm notes/scratch.txt

This deletes the file. Here is the sentence to remember: there is no trash can on the command line. On a graphical desktop, "delete" usually moves a file to a bin you can open and restore from. rm does not. The file's name is removed immediately, and the space is made available for reuse. Treat the command as irreversible.

Because of that, rm rewards a tiny ritual. First run ls notes/scratch.txt (or just ls notes) and confirm that the exact name you typed is the file you mean. Then run rm with the same name. The ls step costs three seconds and has prevented countless regrets.

---

rm -r: removing a folder and everything under it

Plain rm will not remove a directory; it prints a message saying the target is a directory. Add -r to remove a folder and all its contents, level after level:

rm -r drafts_copy

That single line erases drafts_copy and every file and subfolder inside it. There is no "are you sure?" by default, and no way back. For an empty folder there is a gentler tool, rmdir, which refuses to touch anything that still has contents; it is a built-in safety catch.

You will see advice online combining -r with -f (force) to silence all warnings. Do not adopt that habit while learning. Forcing removes the last chance the system has to stop you.

---

Wildcards raise the stakes

The shell can expand patterns such as *.txt into a list of matching names before the command runs. That is powerful and risky: rm notes/*.txt removes every text file in notes/.

The safe technique is to rehearse with ls. Run ls notes/*.txt first. The shell expands the pattern the same way, so you see precisely the files that rm would delete. If the list matches your intention, recall the command and replace ls with rm. If it shows a file you want to keep, you have just avoided a mistake.

---

An ordered workflow

Because copying is safe, moving is mostly safe, and removing is permanent, a good routine follows that order. Here it is as a rhythm you can apply to almost any tidy-up:

1. Make the place first. mkdir -p archive/2026 gives your files somewhere to go.
2. Copy before changing anything valuable. cp notes/tides.txt notes/tides_backup.txt.
3. Edit the working file, using the tools from the last module.
4. Move or rename once you are happy: put finished material where it belongs.
5. Remove last, and only after you have looked at what is left and confirmed that everything you need exists elsewhere.

Notice that deletion is the final step, not the first. If something goes wrong earlier, you still have the copy. If you delete early, you have only your memory.

---

The no-undo ethic

All of the above can be summarised as an attitude rather than a rule. On the command line, the machine trusts you. It assumes that if you typed a command, you meant it. Your side of the bargain is to build small pauses into your practice:

• Run pwd to confirm where you are.
• Run ls to confirm what is there, and before rm, to confirm what will vanish.
• Prefer -i while you are learning.
• Keep a copy of anything you would be sad to lose.
• Delete in a separate, deliberate step, never as part of a hurry.

Experienced users are not people who never make mistakes. They are people who arranged their habits so that mistakes are small and recoverable.

---

Pitfalls worth naming

• Reversed arguments. cp new.txt old.txt overwrites old.txt. Say the command aloud: "copy FROM here TO there."
• Nested folder surprise. Repeating cp -r drafts archive can create archive/drafts when you expected a fresh copy.
• Rename versus move. A destination that is an existing folder means "place inside"; otherwise it means "new name."
• Overwrite by moving. mv replaces an existing destination file without asking.
• Wrong directory. Relative names depend on pwd. Check it before deleting anything.
• Wildcard sweep. A pattern like * can match far more than you pictured. Rehearse with ls.
• Deleting first. Removing "just to clean up" before confirming the copy exists is how files are lost.

---

Self-study checklist

Work through these inside ~/cli-practice/tidewatch, using throwaway files:

• [ ] I can copy a file to a new name and show that changing one leaves the other alone.
• [ ] I can copy a file into archive/ without renaming it.
• [ ] I can copy a folder with cp -r and explain what happens if I repeat the command.
• [ ] I can rename a file with mv and move a file into a folder, and say which is which.
• [ ] I have used cp -i or mv -i and answered the overwrite question.
• [ ] I can delete a practice file with rm after confirming it with ls.
• [ ] I can remove a practice folder with rm -r and I understand there is no way back.
• [ ] I can recite the workflow: make, copy, edit, move, remove last.

---

Summary in plain words

cp duplicates and leaves the original alone; the copy is independent. cp -r does the same for folders. mv either renames (new name) or relocates (existing folder as destination) and does not leave a copy behind. rm deletes files for good, and rm -r deletes folders and everything inside them for good. Because the last one cannot be undone, work in the order make, copy, edit, move, remove last, look with ls and pwd before each risky step, and keep your practice inside a disposable folder.

Worked examples — Sam tidies the tidewatch project

Each story below follows the same pattern: a scene, the steps to type, an interpretation of what happened, and a takeaway to carry forward. Work inside ~/cli-practice/tidewatch; if your folders are missing, rebuild them first with mkdir -p notes drafts scripts archive data/raw data/processed.

---

Example 1 — A backup before a risky edit

Scene. Sam has a file notes/tides.txt with several readings and plans to reorganise it heavily. Sam would like a safety net first, and then wants proof that the net really is separate from the original.

Steps.

cd ~/cli-practice/tidewatch
ls notes
cp notes/tides.txt notes/tides_backup.txt
ls notes
echo "Low tide at 19:20" >> notes/tides.txt
cat notes/tides.txt
cat notes/tides_backup.txt

The first ls shows tides.txt alone. After cp, the second ls shows tides.txt and tides_backup.txt side by side. Then Sam appends a new reading to the original only, and compares the two files with cat.

Interpretation. The original file now ends with Low tide at 19:20, while the backup stops one line earlier. That gap is the proof of independence: after the copy is made, the two files are strangers. If Sam ruins the original during the reorganisation, tides_backup.txt still holds the earlier state and can be copied back.

Takeaway. Copy first, edit second. A copy is cheap, and its independence is the whole point.

---

Example 2 — Copying a folder, and the nested surprise

Scene. Sam wants a spare of the whole drafts/ folder, with two small files already inside, before trying out some ideas. This time the surprise is on purpose, so that it becomes familiar.

Steps. First, a plain attempt, to see the refusal:

cp drafts drafts_spare

The terminal replies that drafts is a directory and was not copied. Sam adds the recursive option:

cp -r drafts drafts_spare
ls drafts_spare

The listing shows the same two files that live in drafts/. Out of curiosity, Sam runs the very same command again:

cp -r drafts drafts_spare
ls drafts_spare

Now the listing shows the two files and a folder named drafts.

Interpretation. On the first successful run, drafts_spare did not exist, so cp -r created it as the copy. On the second run it already existed, so the command put a fresh copy inside it, producing drafts_spare/drafts/. Nothing broke, but the layout is not what Sam wanted. Running ls on the destination before copying would have predicted that.

Takeaway. Use -r for folders, and glance at whether the destination already exists, because that decides where the copy lands. Clean up an accidental nesting with a deliberate, checked removal.

---

Example 3 — Rename versus move with the same command

Scene. Sam has notes/tides_backup.txt. The name is vague. Sam wants to rename it to something dated, and then file it away in archive/. These look like two jobs but both use mv.

Steps.

mv notes/tides_backup.txt notes/tides_monday.txt
ls notes
mv notes/tides_monday.txt archive/
ls notes
ls archive

After the first mv, ls notes shows tides_monday.txt where tides_backup.txt used to be. After the second mv, ls notes no longer lists it, and ls archive does.

Sam then tries one combined step with a second file:

mv notes/plan.txt archive/old_plan.txt
ls archive

Interpretation. In the first command the destination, notes/tides_monday.txt, was not an existing folder, so mv read it as a new name: a rename. In the second, archive/ was an existing folder, so mv placed the file inside it: a move. The third gave a folder plus a new file name, so the file moved and was renamed at once. In none of these did a second copy appear; the original name vanished each time.

Takeaway. Ask one question before each mv: is the destination an existing folder? Yes means "put inside," no means "call it this."

---

Example 4 — A careful delete, with a rehearsal

Scene. The notes/ folder has three scratch files: scratch1.txt, scratch2.txt, and, regrettably, scratch_keep.txt, which holds a reading Sam still needs. Sam wants to clear the scratch files but is tempted to type a wildcard.

Steps. Instead of deleting straight away, Sam rehearses:

ls notes/scratch*.txt

The output lists all three files, including scratch_keep.txt. The pattern is too wide. Sam narrows it:

ls notes/scratch[0-9].txt

Now only scratch1.txt and scratch2.txt appear, which is the intended set. Sam recalls the command and swaps ls for rm:

rm notes/scratch[0-9].txt
ls notes

The final listing shows scratch_keep.txt still standing and the two scratch files gone.

For a leftover folder, Sam confirms the name and then removes it:

ls drafts_spare
rm -r drafts_spare
ls

The last ls no longer shows drafts_spare.

Interpretation. Because the shell expands patterns before rm runs, ls with the same pattern is a faithful preview of what will be deleted. That rehearsal exposed an over-broad pattern at no cost. After the real deletion there was no recovery step available, which is why Sam spent the three seconds first. rm -r removed the folder and all its contents in one command, again with no way back.

Takeaway. Preview with ls, then delete with the identical pattern. Deletion is permanent, so the preview is the only undo you get.

---

Example 5 — The ordered workflow from start to finish

Scene. Sam must produce a cleaned weekly file from notes/tides.txt and file the old version away, ending with a tidy folder. This example strings the whole module together in the safest order.

Steps.

pwd
mkdir -p archive/week1
cp notes/tides.txt notes/tides_backup.txt
nano notes/tides.txt
mv notes/tides_backup.txt archive/week1/
ls notes archive/week1

Reading it line by line: pwd confirms Sam is in tidewatch. mkdir -p creates the destination archive/week1 first, so the later move has somewhere to go. cp makes the backup. nano opens the working file for the tidy-up, which Sam saves with Ctrl+O, Enter, and Ctrl+X. mv then files the backup into the archive. The final ls shows tides.txt in notes and tides_backup.txt in archive/week1.

Only now, after comparing both listings and confirming that the archived copy exists, does Sam delete a leftover test file:

ls notes/scratch1.txt
rm notes/scratch1.txt

Interpretation. Each step used the safest tool that could do the job, and removal came last, once everything needed was confirmed to exist elsewhere. Had the edit gone wrong, the backup was still on hand. Had Sam removed anything early, that safety would have been gone.

Takeaway. Make, copy, edit, move, remove last. When the order is habitual, accidents have far less room to occur.

---

Before you move on

Rebuild Example 5 in a fresh practice folder without looking at the commands. Say each step aloud as you type it: "make the place, copy the file, edit the copy, move the backup, delete last." If you can narrate the order, you own it.