Module 0.3: First Terminal Commands

Complexity: [QUICK] - Follow along and type what you see

Time to Complete: 25 minutes

Prerequisites: Module 0.1 - What is a Computer?

---

What You’ll Be Able to Do

After this module, you will be able to practice the following skills in a real terminal session and explain why each command is useful before you rely on it in later labs:

• Navigate directory paths with pwd, ls, and cd, then diagnose when a command ran in the wrong place
• Create folders and files with mkdir, touch, cp, and mv, then compare copy versus move behavior
• Delete files safely with rm by evaluating risk, confirming targets, and cleaning up only intended paths
• Combine command output with pipes and filters to inspect files without opening a graphical app

Why This Module Matters

Hypothetical scenario: you are following a setup guide for a Kubernetes practice lab, and the guide tells you to create a configuration folder, copy a sample file, rename it, and remove the old version. The instructions look simple until you realize that every command acts on your current location. If you are in the wrong directory, the command may still succeed, but the file lands somewhere surprising, the copy is not where the next step expects it, or the cleanup command removes a path you meant to keep.

That is why first terminal commands are not trivia. They are the control surface for almost every later task in this curriculum: editing manifests, collecting logs, moving through project folders, running kubectl, and checking what changed after a command. The terminal is not harder than a graphical interface in principle; it is simply less visual and more literal. It does exactly what you ask in the place where you are standing, so your first job is to learn how to stay oriented.

By the end of this module, you will have practiced nine commands that cover a large share of everyday terminal work: pwd, ls, cd, mkdir, touch, cp, mv, rm, and clear. You will also see why pipes are the bridge from “I can run one command” to “I can inspect a system quickly.” This is still a beginner module, but the habits are professional habits: check location before action, prefer reversible steps when possible, and treat deletion as a decision rather than a reflex.

There is another reason this module matters early: terminal mistakes often look like tool mistakes. A learner runs a command, sees output that does not match the guide, and assumes the operating system, course, or shell is broken. Very often the command was correct, but it ran from the wrong directory or acted on a different file than the learner imagined. The fastest way to debug those moments is not a complicated trick; it is the discipline of asking where you are, what is here, and what changed.

You should also expect the terminal to feel slightly uncomfortable at first because it gives less visual feedback than clicking through folders. That discomfort is normal, and it fades as your mental model improves. The goal of this module is not to make you type fast. The goal is to make each command feel explainable: you should know what location it uses, what target it changes, what output proves it worked, and what risk would make you slow down.

Opening Your Terminal and Reading the Prompt

Before we run commands, open a terminal in the environment you are using for this course. On macOS, press Cmd + Space, type “Terminal”, and press Enter, or open Terminal from Applications > Utilities. On Linux, Ctrl + Alt + T opens a terminal on many desktop environments, and the application menu usually has a Terminal entry as well. On Windows, this module is written for a Unix-style shell such as Windows Subsystem for Linux, because native PowerShell has different names and defaults for several commands.

When the terminal opens, you should see a short line of text ending in a symbol such as $ or %. That line is called the prompt because it is prompting you to type the next command. The exact text varies by machine, shell, and theme, so do not worry if yours does not match the example exactly. What matters is that the terminal is waiting for one complete instruction, and it will not guess beyond what you typed.

username@computername ~ $

The prompt usually includes some combination of your user name, computer name, and current directory. The ~ symbol is especially important because Unix-style shells commonly use it as shorthand for your home directory, which is the personal area where your user files live. Think of the prompt as a small location badge on your screen: it tells you who is acting, where the action will happen, and when the shell is ready for another command.

Notice that a terminal command is just text followed by Enter. Some commands have flags, which are small options such as -l or -a that change behavior, and some commands have arguments, which are the files or directories the command should act on. The pattern is not universal, but a useful beginner model is “command, options, target.” When a command surprises you later, ask which part of that pattern you may have misread.

Navigate Directory Paths with pwd, ls, and cd

Your computer organizes files in a tree structure, which means every file and folder has a location relative to a top-level root. A graphical file manager hides much of that structure behind windows and icons, but the terminal asks you to name locations directly. That may feel strict at first, yet the strictness is useful: once you can describe a location as a path, you can automate it, copy it into documentation, and run the same operation on a remote server where no graphical desktop exists.

/ (the root -- the building itself)
├── Users/
│   └── yourname/          ← This is your "home directory"
│       ├── Desktop/
│       ├── Documents/
│       ├── Downloads/
│       └── Pictures/
├── Applications/
└── System/

In this restaurant-floor-plan analogy, the root directory is the building, your home directory is your private office, and folders such as Desktop or Documents are rooms inside that office. The terminal always has a current working directory, which is the room where relative paths begin. If you say Documents, the shell interprets that relative to where you are now; if you say /Users/yourname/Documents, you are giving a full path from the building entrance.

The first command is pwd, which stands for print working directory. It answers the question “Where am I right now?” before you create, copy, move, or delete anything. Professionals use it constantly because being wrong about location is one of the simplest ways to create confusing results. In a Kubernetes project, for example, running a command from the wrong checkout can make you edit an old manifest while your active cluster still uses a different file.

pwd

The expected output is a full path to your current directory, and yours will differ because your user name and operating system are specific to your machine:

/Users/yourname

On Linux, the same idea often appears as /home/yourname, while a Windows PowerShell prompt may show a path like C:\Users\yourname. The exact spelling is less important than the habit: read the output as a location, not as decoration. If you expected to be inside a project folder and pwd says you are still in your home directory, stop and navigate before you create files.

The second command is ls, which lists what is in the current directory. It is the terminal equivalent of opening a drawer and looking inside. Plain ls gives you names, which is often enough when you are checking whether a folder or file exists. Because it acts on your current directory by default, it pairs naturally with pwd: first ask where you are, then ask what is there.

ls

Expected output will show the visible entries in your own home directory, so treat this as a shape example rather than text that must match exactly:

Desktop    Documents    Downloads    Music    Pictures

The long form, ls -l, shows more context, including permissions, ownership, size, and modification time. You do not need to understand every column yet, but you should notice that flags change the amount of information a command returns. The rightmost column is the name, and the date tells you when the item was last changed. During real troubleshooting, that date can be the clue that a configuration file changed shortly before a failure.

ls -l

The long-format output below is only a sample, but it shows the kind of metadata ls -l adds beside each name:

drwx------   4 yourname  staff   128 Mar 15 10:30 Desktop
drwx------   5 yourname  staff   160 Mar 20 09:15 Documents
drwx------  12 yourname  staff   384 Mar 22 14:45 Downloads

Pause and predict: if plain ls shows only names and ls -l shows more detail, what do you expect a command named ls -la to add? Think about what kinds of files a graphical file manager might hide by default. Then run it in your own home directory and compare the output to plain ls, paying attention to names that start with a dot.

ls -la

The -a flag means “all”, including hidden files whose names begin with a dot. Hidden does not mean secret or malicious; it usually means “configuration file that would clutter normal browsing.” Shell startup files, editor settings, and tool caches often live this way. Beginners sometimes delete dotfiles because they look unfamiliar, but many of them control how your shell or development tools behave.

The third command is cd, which stands for change directory. It changes your current working directory, so every relative path after that begins from the new place. This is like walking from your office into the Documents room before picking up a folder. Nothing has been created or deleted by cd; only your point of view has changed.

cd Documents

After changing directories, immediately check where you are so you connect the cd action with the path change it produced:

pwd

The output should now include the Documents directory at the end of the path, showing that your current working directory changed:

/Users/yourname/Documents

That pair of commands shows the core navigation loop: move with cd, verify with pwd, and inspect with ls. The loop is intentionally simple because it needs to become automatic. If you later run kubectl apply -f deployment.yaml, the shell has to find deployment.yaml from your current directory unless you provided a longer path. Knowing where you stand is part of knowing what command you actually ran.

Going back up: cd ..

The special path .. means “the parent directory”, or the room that contains the current room. If Documents is inside your home directory, then cd .. moves you from Documents back to home. This is not a command-specific trick; .. is a standard path component used across Unix-style systems. You will see it in terminal work, scripts, and documentation.

cd ..

pwd

The output should now be back at your home directory because .. moved one level up from Documents rather than jumping somewhere unrelated:

/Users/yourname

Going home: cd ~

The ~ symbol is a shortcut for your home directory in many Unix-style shells. No matter how deep you are in a project, cd ~ returns you to the personal base directory for your account. This is useful when you feel lost, but it is also useful when instructions intentionally start from a known safe place. Many beginner labs begin with cd ~ because it removes ambiguity before creating practice folders.

cd ~

Going to a specific place: cd /path/to/place

Sometimes you do not want to walk one room at a time. A full path lets you jump directly to a location from the root of the file system. The /tmp directory is commonly available on Unix-like systems for temporary files, so it makes a useful example. Do not store important work there unless you know your system’s cleanup policy, because temporary directories are designed for disposable data.

cd /tmp

pwd

The output should show the temporary directory, proving that an absolute path can jump directly to a location:

/tmp

Now return home so the next practice commands start from a familiar and relatively safe location that you can verify again:

cd ~

Before running this in your own terminal, what output do you expect from pwd after cd ~? Make the prediction first, then run pwd and compare. This small habit matters because prediction turns terminal practice from copying into reasoning; you are building a mental model, not memorizing a list.

Create Folders and Files with mkdir, touch, cp, and mv

Navigation tells you where commands will act, but useful work begins when you create and rearrange files. These commands are intentionally small. mkdir creates directories, touch creates an empty file when the file does not exist, cp creates another copy, and mv changes a file’s name or location. The power comes from combining those small actions with precise paths.

The safest way to learn creation commands is to run them in a practice area, not in a folder full of important work. Start from your home directory and create a clearly named folder so you can recognize it later. Names with dashes are convenient because they avoid the quoting problems that spaces introduce. Spaces are allowed in file names, but they require care because the shell uses spaces to separate words.

mkdir stands for make directory. A directory is a folder, and creating one does not move you into it automatically. This is a common beginner assumption: after mkdir my-first-folder, your current directory is still wherever it was before. Use ls to verify that the folder exists, and use cd my-first-folder only when you intentionally want to enter it.

mkdir my-first-folder

Check that the directory was created by listing the current directory and looking for the new name among the existing entries:

ls

You should see my-first-folder in the list. If you do not, run pwd and ask whether you created it somewhere else. If mkdir reports that the directory already exists, that is not mysterious; it means the name is already taken in the current directory. You can choose another name, remove the old practice folder after checking it, or reuse the existing folder if that is what you intended.

The -p flag makes mkdir create missing parent directories along a path. Without -p, mkdir restaurant/kitchen/prep-area fails if restaurant or restaurant/kitchen does not already exist. With -p, the command creates the whole chain as needed. The flag is popular in scripts because it makes setup commands repeatable: running the same command again does not fail simply because the directory already exists.

mkdir -p restaurant/kitchen/prep-area

This creates three folders nested inside each other, even though restaurant and kitchen did not exist yet. The word “parents” is a helpful memory aid: a child directory cannot exist unless its parent directories exist first. In project work, this pattern appears when you create paths such as app/frontend/components or manifests/base/deployments before adding files inside them.

touch creates an empty file if the named file does not exist. The command originally exists to update timestamps, so if the file already exists, touch changes its modification time rather than replacing its contents. For a beginner, the practical use is simple: create a blank file so you have something concrete to copy, move, or delete. Empty files are also common placeholders in labs because they let you practice path operations without needing a text editor yet.

touch menu.txt

Check the current directory so you can see the empty file name appear beside the folders you already created:

ls

You will see menu.txt in your list. It is empty, like a blank sheet of paper waiting to be written on. If you accidentally run touch in the wrong directory, the file will still be empty and harmless, but its location will confuse later steps. That is why the pwd, ls, action loop matters even for simple commands.

cp stands for copy, and it creates a duplicate while leaving the original in place. This distinction is critical when you are preserving a known-good version before experimenting. A copy gives you a fallback; a move does not. When you later edit configuration files, copying a file before changing it can be a simple safety measure, although professional version control is the stronger long-term habit.

cp menu.txt menu-backup.txt

Now you have two files: the original and the copy, which is exactly the behavior you want when you need a fallback before experimenting.

ls

The output should include both file names, which proves that cp duplicated the original file rather than moving or renaming it:

menu-backup.txt    menu.txt    my-first-folder    restaurant

To copy a file into a folder, provide the source file and the destination directory. The trailing slash in restaurant/ is not always required, but it communicates your intent clearly: the destination is a directory, not a new file name. If the directory does not exist, the command will fail rather than create the directory for you. That separation is useful because mkdir owns directory creation, while cp owns copying.

cp menu.txt restaurant/

To copy an entire folder and everything inside it, use -r, which means recursive. Recursive operations walk through a directory tree, acting on the directory and its children. This is convenient, but it also deserves respect because one command may touch many files. For copying, the risk is usually clutter or confusion; for deletion, recursive behavior can be destructive.

cp -r restaurant restaurant-copy

mv stands for move, but it also renames. This seems odd until you realize that a file’s name is part of its path. Moving menu-backup.txt into restaurant/ changes its path from ./menu-backup.txt to ./restaurant/menu-backup.txt. Renaming menu.txt to daily-specials.txt changes only the final path component, but the underlying operation is still “change where this file is known.”

When moving a file to another folder, read the command as source first and destination second before pressing Enter:

mv menu-backup.txt restaurant/

The file is no longer in the current directory because it has been moved into the restaurant folder. Unlike cp, the original does not stay behind. This is exactly what you want when reorganizing a project, but it is wrong when another tool still expects the original location to exist. When in doubt, copy first, inspect the result, and move only when you are sure there should be one file rather than two.

When renaming a file, the same source-then-destination pattern applies even though the destination is a new name in the same directory:

mv menu.txt daily-specials.txt

The file menu.txt is gone under that name, and daily-specials.txt appears in its place. It is the same file with a new name, not a duplicate. Which approach would you choose here and why: copying a sample configuration before editing it, or moving it into place immediately? A cautious answer is to copy when you are exploring and move when you are completing a deliberate reorganization.

Delete and Clean Up Safely with rm and clear

Deletion is where terminal precision becomes most important. A graphical desktop usually gives you a trash or recycle bin, and it may ask for confirmation before permanent removal. The terminal’s rm command is more direct. It removes file names immediately and usually has no built-in undo path for ordinary users. That does not mean you should fear it; it means you should build a confirmation routine before using it.

Stop and think: when you delete a file by dragging it to the Trash on your desktop, where does it go? You can often recover it because the graphical environment moved it to a holding area. Now compare that with a terminal command that is designed for scripts, remote servers, and automation. A command meant to run without a person clicking confirmation boxes cannot rely on a visual trash workflow.

rm stands for remove. It deletes a file at the path you provide, or in the current directory if you provide only a file name. Before you run it, use pwd to confirm where you are and ls to confirm the target name. If there is any doubt, stop. A few seconds of checking is cheaper than rebuilding work you removed from the wrong directory.

rm daily-specials.txt

The file is gone. More precisely, the directory entry is removed immediately, and normal shell usage does not provide an Undo button. Specialized recovery may sometimes be possible before data is overwritten, depending on file system and storage details, but that is not a workflow you should rely on. Treat rm as a final action unless you have a backup, a copy, or a version-control history.

For a real example of why backups matter, Pixar’s Toy Story 2 production nearly lost a large amount of work after files were removed from production storage. The team recovered because a supervising technical director had a copy outside the main system, but the incident still required reconstruction. This example is not here to dramatize the terminal; it is here to show the practical relationship between destructive commands and recovery planning.

That relationship becomes more important as you move from practice files to real project work. A disposable folder named restaurant can be rebuilt in seconds, but a generated report, a downloaded certificate, or a hand-edited configuration file may represent work you cannot easily recreate. The terminal cannot know which file matters to you. It sees paths and permissions, not intent, so you have to supply the intent by choosing narrow targets and verifying them before destructive operations.

One practical safety technique is to separate cleanup into two phases. First, inspect or move the target into a clearly named holding place, such as a temporary cleanup folder. Second, delete only after you are sure the contents are disposable. You will not always need that extra step, especially in small practice labs, but the pattern teaches a useful instinct: when the cost of being wrong is high, make the operation more reversible before you make it final.

To delete a folder and everything inside it, add -r for recursive behavior. This tells rm to walk the directory tree below the target and remove contained files and directories. The command is useful for cleaning up a practice folder, build output, or a temporary workspace. It is also one of the places where a typo can hurt, so inspect the target before pressing Enter.

rm -r restaurant-copy

The -r flag means “recursive”, which is the same idea you saw with cp -r, but now the action is removal rather than copying. Be especially careful with commands copied from the internet that include rm -rf, where -f asks for forceful removal and suppresses many prompts. You do not need -f for this module. The safer beginner habit is to remove known practice directories by explicit name after listing their contents.

A classic dangerous example is shown below only so you recognize why engineers warn about it. Do not run it. On modern GNU/Linux systems, rm normally refuses to operate on / because of the default --preserve-root safety guard, and disabling that guard requires an explicit unsafe option. The presence of a guard does not make careless deletion safe; it only blocks one especially catastrophic form.

rm -rf /

clear is different from rm because it affects only the display, not your files. It scrolls old output out of view so you can start with a clean screen. This is useful during practice because a cluttered terminal makes it harder to tell which output belongs to which command. If you clear the screen accidentally, nothing has been deleted, and you can usually scroll back in the terminal window.

clear

Your screen is now clean. Nothing was removed from disk, and command history still exists in the shell. On most terminals, Ctrl + L performs a similar screen-clear action. Use clear when you want visual focus, not as a substitute for cleaning files. For files and directories, you still need rm, and you still need the caution that comes with it.

Combine Commands with Pipes and Filters

Once single commands feel comfortable, pipes introduce the main reason terminal work scales so well. A pipe, written as |, sends the output of the command on the left into the command on the right. Instead of making one command do everything, Unix-style tools encourage small commands that do one job and pass text along. This is the assembly-line model: one station lists files, the next station trims the list, and another station searches for a pattern.

This section is still introductory, so you do not need to master every filtering tool today. The important idea is that terminal output can become input. That idea appears constantly in professional work: searching logs, narrowing process lists, finding changed files, and scanning command history. Later Kubernetes commands also produce text or structured output that you will filter when a cluster has too much information to read manually.

The first pipeline shows only the first 5 files, which is useful when a directory listing would otherwise push useful output off the screen:

ls | head -5

ls lists entries, but head -5 keeps only the first 5 lines. This is useful when a directory has hundreds of files and you want a quick sample without flooding the screen. The left command does not need to know that head exists, and head does not need to know how ls found the names. The pipe connects them by text.

The second pipeline searches for a word inside a file, turning a full file display into a focused question about matching lines:

cat daily-specials.txt | grep "pasta"

cat displays file contents, and grep "pasta" filters to lines containing the word pasta. You will use grep often because systems produce more text than humans can read line by line. There are more efficient ways to use grep directly on files, but this pipeline is a clear first example: produce text, then filter text. The habit matters more than the specific food word.

The third pipeline finds a past command you typed, which is a practical way to recover a path or option from recent shell history:

history | grep "mkdir"

history shows commands you have typed in the shell, and grep "mkdir" narrows the output to commands that included mkdir. This is handy when you remember part of a command but not the exact path. It also teaches a gentle diagnostic pattern: when the screen has too much information, do not read harder; filter better. The terminal rewards precise questions.

Before running your own pipeline, predict which side of the pipe runs first and what text moves across the pipe. Then try changing the search word in the history | grep "mkdir" example to cd or rm. If a command returns no output, that does not always mean failure; it may mean the filter found no matching lines. Empty output is still information when you know what question you asked.

Quick Reference Card

The table below keeps the original command set close at hand while you practice. Do not try to memorize it by staring at it. Use it as a map while you run small tasks, because memory forms faster when each command solves a concrete problem. The kitchen analogy is intentionally simple: it links an unfamiliar terminal verb to an everyday action, then the later sections add precision.

Command	What It Does	Kitchen Analogy
pwd	Shows where you are	”What room am I in?”
ls	Lists what’s here	”What’s on this shelf?”
cd	Moves to another place	”Walk to another room”
mkdir	Creates a new folder	”Build a new room”
touch	Creates an empty file	”Put a blank paper on the counter”
cp	Copies a file	”Photocopy this recipe”
mv	Moves or renames	”Move this to another shelf” or “relabel it”
rm	Deletes immediately	”Shred this paper” (no recycle bin by default)
clear	Cleans the screen	”Wipe the whiteboard”

The reference card also shows an important design principle: the command names are short because they come from environments where typing mattered and screens were limited. Short names are not meant to be cryptic forever. After a little practice, pwd becomes “where am I”, ls becomes “what is here”, and cd becomes “go there.” The goal is fluency, not reciting expansions.

When This Doesn’t Apply

The terminal is not the best tool for every file task, and professional engineers use graphical tools when those tools fit the job. If you are visually sorting a large photo library, previewing design assets, or dragging a file into another desktop application, a graphical file manager may be faster and less error-prone. Choosing the terminal should be a decision based on precision, repeatability, remote access, or automation, not a badge of seriousness.

The terminal becomes the better choice when the action has to be exact, repeated, documented, or performed on a machine you can reach only through a shell. Creating the same directory structure across environments, copying a known file into a known place, filtering a long command history, or cleaning a disposable practice folder are all strong terminal use cases. The same logic later applies to Kubernetes: graphical dashboards can help you inspect, but command-line workflows are easier to repeat and share.

A practical rule is to use the graphical interface when your eyes are making the decision and the terminal when the path or pattern is making the decision. Visual browsing is excellent when you do not know what you want yet. Terminal commands are excellent when you can name exactly what you want. As you gain experience, the two approaches stop competing and start complementing each other.

There is also a middle ground worth noticing. Many editors and development environments include an embedded terminal beside a file tree. That layout is popular because it lets your eyes and commands support each other: you can inspect the project visually, run precise commands from the same root, and notice immediately when files appear or move. If you use an embedded terminal, remember that it still has a current working directory. The surrounding editor does not remove the need for pwd.

When You’d Use This vs Alternatives

Use pwd, ls, and cd when your problem is orientation. They are the right tools when you need to confirm location, inspect a directory, or move to the correct workspace before acting. Use a graphical file manager instead when you need thumbnails, previews, or visual comparison. The tradeoff is speed versus visibility: terminal navigation is precise and scriptable, while a graphical browser shows context that may not fit neatly in text.

Use mkdir, touch, cp, and mv when your problem is controlled file organization. They are good when you can name the exact directory or file and want a repeatable action. Use an editor, integrated development environment, or file manager when you need to author content, compare documents visually, or drag files between applications. The tradeoff is that terminal commands are efficient after you know the target, but they are unforgiving when the target is vague.

Use rm only when your problem is deliberate cleanup and you have confirmed the target. If you are unsure whether a file matters, prefer moving it into a temporary holding directory, making a copy, or leaving it alone until you can inspect it. Use clear when your problem is visual clutter, not disk clutter. These two commands are often confused emotionally because both make things disappear from view, but only one removes files.

Use pipes when your problem is too much output rather than too little output. A graphical search box can be comfortable for a single document, but a command pipeline can search command history, file listings, and tool output without opening separate windows. The tradeoff is that pipes require you to think about text flow: left command produces, right command filters. Once that model clicks, the terminal becomes less like a set of isolated commands and more like a small inspection language.

Did You Know?

• Command-line interfaces became common long before graphical mouse-and-windows interfaces became mainstream. Computers used text-only interfaces from the 1960s until the mid-1980s. The graphical mouse-and-windows interface you’re used to was popularized by the Apple Macintosh in 1984. When you use a terminal, you’re using the original way humans talked to computers.
• ls is among the oldest commands still widely used today. It traces back to the Compatible Time-Sharing System (CTSS) at MIT in the early 1960s, where a similar command was named LISTF. The modern ls appeared in the first version of Unix around 1971. You’re using a command with more than 50 years of lineage.
• The ~ (tilde) for home directory comes from a keyboard accident. On early terminals, the Home key and the ~ key were on the same physical key. The convention stuck, and many Unix-like shells now use ~ to mean “home.”
• The pipe operator made text tools composable instead of monolithic. Unix pipelines let one program’s output become another program’s input, which is why small tools such as ls, head, cat, grep, and history can solve larger inspection tasks without each tool knowing about the others.

Common Mistakes

Mistake	Why It Happens	How to Fix It
Using rm without checking first	The command is short, and beginners expect desktop-style Trash behavior	Run pwd and ls first, then remove only the exact target you meant to remove
Forgetting -r when copying or removing folders	Directories contain other entries, so the command needs permission to recurse	Use cp -r folder newname for directory copies and rm -r folder only after inspecting the folder
Creating names with unquoted spaces by accident	The shell treats spaces as separators between arguments	Use quotes such as mkdir "my folder" or prefer dashed names such as mkdir my-folder
Getting lost in the file system	cd changes context silently when it succeeds	Type pwd frequently, use cd ~ to return home, and inspect with ls before acting
Confusing cp and mv during cleanup	Both commands take a source and a destination, but only one leaves the original behind	Use cp when you need a duplicate or fallback, and mv when there should be one final location
Assuming mkdir moves you into the new folder	Graphical tools often open a folder after creation, but mkdir only creates it	Run cd folder-name after mkdir if you want to enter the new directory
Treating empty output as always bad	Filters such as grep may return nothing when no lines match	Recheck the question you asked, try a broader pattern, or inspect the unfiltered command output
Typing commands wrong and getting frustrated	Everyone mistypes paths, flags, and file names, especially at speed	Use the up arrow to recall the previous command, edit carefully, and rerun only after reading it

Quiz

1. Your team runs `mkdir projects`, but the folder appears in a completely unexpected location. What should you have checked before creating it, and how do you diagnose the mistake afterward?

You should have run pwd before mkdir to confirm your current working directory. mkdir projects creates the folder relative to where the shell is standing, so a successful command can still create the folder in the wrong place. Afterward, run pwd to see where you are, then use ls in that location to confirm whether projects was created there. The fix is not to guess harder; it is to restore the navigation loop of pwd, ls, and cd.

2. You need a logo file to remain in `assets/` while another copy goes into `public/`, and later you need a config file relocated without leaving a duplicate. Which command fits each task, and why?

Use cp for the logo because the requirement explicitly needs two files: the original in assets/ and a duplicate in public/. Use mv for the config file because the requirement says it should be relocated without leaving a duplicate behind. The important comparison is copy versus move behavior, not the spelling of the commands. If you choose mv for the logo, you break the original location; if you choose cp for the config, you may leave stale configuration behind.

3. You are cleaning old logs and accidentally type `rm production-db.sql` instead of `rm production.log`. What happens next, and what habit would have reduced the risk?

The terminal does not give you a normal desktop Undo button or Trash recovery path for rm. The file name is removed immediately, and ordinary users should assume recovery is unreliable unless a backup or version-control copy exists. The safer habit is to run pwd and ls first, read the target name slowly, and remove only the exact file you intended. For higher-risk cleanup, move files into a temporary holding directory first, then delete after verification.

4. You need to create `app/frontend/components/buttons/`, but none of the parent folders exist yet. You try plain `mkdir app/frontend/components/buttons/` and it fails. What command should you use, and why?

Use mkdir -p app/frontend/components/buttons/. Plain mkdir can create one directory only when its parent already exists, so it fails when app, frontend, or components is missing. The -p flag tells mkdir to create missing parent directories along the path. This is useful for repeatable setup because the same command can succeed even when part of the structure already exists.

5. You have been navigating through server logs and no longer know where you are, but you need to return to your main user folder before running a script. Which two commands restore your context?

First run pwd to print the current working directory and diagnose where the shell is standing. Then run cd ~ to return to your home directory, which is a known base location for your user account. This pair works because it separates diagnosis from action: pwd tells you the current state, while cd ~ changes it deliberately. After returning home, use ls if you need to confirm the script or project folder is present.

6. You run `history | grep "mkdir"` and nothing appears, even though the command itself did not show an error. How should you interpret that result?

Empty output from a pipeline often means the filter found no matching lines, not that the shell failed. In this case, history produced text, and grep "mkdir" kept only lines containing the word mkdir; if no such lines exist in the visible history, the final output is empty. To diagnose, run history by itself or search for a broader term such as mk. This question tests command output filtering, because pipes answer exactly the pattern you ask for.

7. You copied a practice directory with `cp -r restaurant restaurant-copy`, experimented in the copy, and now want to clean up only the duplicate. What should you inspect, and what removal command fits?

Run ls to confirm that both restaurant and restaurant-copy exist, and use ls restaurant-copy if you want to inspect the duplicate before deleting it. The correct cleanup command is rm -r restaurant-copy, because you are removing a directory tree rather than a single file. Do not remove restaurant unless that original folder is also disposable. The reasoning is the same as all safe deletion: confirm location, confirm target, then run the narrowest command that matches your intent.

Hands-On Exercise: Build a Restaurant File Structure

Exercise scenario: you are preparing a small file layout for an imaginary restaurant, and your job is to create the structure, inspect it, move one item, copy a menu, and clean up the practice workspace. The exercise intentionally uses harmless empty files so you can focus on command behavior rather than file contents. Work slowly, read each path before pressing Enter, and keep the pwd, ls, action loop in mind whenever something does not look right.

Step 1: Go to your home directory

cd ~

Solution notes

Starting from home gives the exercise a predictable base location. If you are unsure whether the command worked, run pwd and check that the path looks like your user directory rather than a project subfolder or temporary directory.

Step 2: Create the restaurant structure

mkdir -p restaurant/kitchen/prep-area
mkdir -p restaurant/kitchen/cooking-stations
mkdir -p restaurant/dining-room
mkdir -p restaurant/storage/pantry
mkdir -p restaurant/storage/freezer

Solution notes

Each command uses mkdir -p because some parent directories do not exist before the command runs. Running these lines more than once should not hurt the practice layout, which is one reason -p is useful in setup instructions.

Step 3: Create some files

touch restaurant/kitchen/prep-area/chopping-board.txt
touch restaurant/kitchen/cooking-stations/grill.txt
touch restaurant/kitchen/cooking-stations/oven.txt
touch restaurant/dining-room/table-1.txt
touch restaurant/dining-room/table-2.txt
touch restaurant/storage/pantry/flour.txt
touch restaurant/storage/pantry/sugar.txt
touch restaurant/storage/freezer/ice-cream.txt

Solution notes

These files are empty placeholders, but their paths prove that the directory structure exists. If one command fails, inspect the spelling of the parent directories with ls restaurant and ls restaurant/kitchen before rerunning the failed line.

Step 4: Look at what you built

ls restaurant/
ls restaurant/kitchen/
ls restaurant/kitchen/cooking-stations/

The expected output for the last command should show the two cooking-station files you created, which confirms that the nested path exists:

grill.txt    oven.txt

Solution notes

The three ls commands inspect the layout at increasing depth. If the final output does not include both files, read the earlier touch commands and check whether a path was misspelled.

Step 5: Move some things around

The ice cream is melting in this exercise scenario, so move it from the freezer path to the prep-area path while reading the source and destination carefully:

mv restaurant/storage/freezer/ice-cream.txt restaurant/kitchen/prep-area/

Verify the move by listing the destination directory instead of assuming the command did what you intended after reading the prompt:

ls restaurant/kitchen/prep-area/

The expected output should include both the original prep-area file and the moved file, confirming that the destination now contains both items:

chopping-board.txt    ice-cream.txt

Solution notes

The mv command changes the file’s location, so ice-cream.txt should no longer be in restaurant/storage/freezer/. If you want to prove that, run ls restaurant/storage/freezer/ and expect no output for that file.

Step 6: Make a backup of the menu

touch restaurant/menu.txt
cp restaurant/menu.txt restaurant/menu-backup.txt
ls restaurant/

Solution notes

This step uses cp because a backup should leave the original in place. The final ls should show both menu.txt and menu-backup.txt in the restaurant directory.

Step 7: Clean up

When you are done experimenting, clean up only the disposable practice directory you created for this exercise, not any similarly named real project:

rm -r restaurant

Verify that the practice directory is gone by filtering the current directory listing for the restaurant name and interpreting empty output carefully:

ls | grep restaurant

No output means it is gone. This is a good example of empty output as useful information: the ls command produced names, and grep restaurant found no matching line after the cleanup.

Solution notes

This cleanup is safe only because restaurant is a disposable practice directory that you created for the exercise. If you are not sure where you are, run pwd before cleanup. If you are not sure what is inside the directory, run ls restaurant before removal.

Use this success criteria checklist to confirm that you practiced every aligned skill rather than only copying commands:

• You used cd ~, pwd, or both to start from a known location.
• You created the nested restaurant directory structure with mkdir -p.
• You created empty practice files with touch in the correct subdirectories.
• You inspected the structure with ls at multiple levels.
• You moved ice-cream.txt with mv and verified the new location.
• You copied menu.txt with cp so the original and backup both existed.
• You removed only the disposable restaurant practice directory with rm -r.
• You used a pipe with grep to verify that cleanup produced no remaining restaurant entry.

Sources

• Command-line interface — Background on text-based computer interfaces and their long use before mainstream graphical systems.
• Classic Mac OS — Overview of the original Macintosh software platform associated with the popularization of GUI computing in 1984.
• Tilde — Explains the historical terminal-keyboard convention behind ~ as a home-directory shorthand.
• Unix shell — Further reading on shells, prompts, commands, and the environment this module introduces.
• ls — Further reading on the ls command, including history and common options.
• Pipeline (Unix) — Further reading on how the pipe operator connects one command’s output to another.
• POSIX pwd — Standard behavior for printing the working directory.
• POSIX ls — Standard listing utility behavior and options.
• POSIX mkdir — Standard directory creation utility behavior.
• POSIX touch — Standard timestamp update and file creation utility behavior.
• POSIX cp — Standard copy utility behavior, including recursive copying.
• POSIX mv — Standard move and rename utility behavior.
• POSIX rm — Standard removal utility behavior and recursive deletion options.
• GNU Coreutils manual — Reference documentation for common GNU command-line utilities.

Next Module

In Module 0.4: Files and Directories, you will go deeper into how computers organize files and folders, then practice navigating paths with more confidence and less guessing.