Module 1.1 — The shell and paths

Imagine you have just joined a small coastal observation project called tidewatch. Before you can help, you need a feel for the terminal and a reliable way to say where something is.

By the end you should be able to: explain terminal vs shell; split a command into program, options, and arguments; tell absolute paths from relative ones; use ., .., ~, and pwd; remember case sensitivity and quoting spaces.

Scroll Core ideas → worked examples → Quiz. Practice inside ~/cli-practice on any Linux, macOS, or WSL terminal (bash / zsh). Plan on roughly 55–60 minutes if you type the commands yourself.

Core ideas — the shell, commands, and paths

If you have only ever opened files by double-clicking icons, the command line can feel like stepping into a room with no furniture: a blinking cursor and nothing else. This lesson furnishes that room. We will name the pieces (terminal, shell, command, path), explain how they fit together, and give you a small set of habits that prevent the most common early confusion. Throughout, we will use a made-up project called tidewatch, a coastal observation effort whose files live under ~/cli-practice/tidewatch/. You will meet its owner, a learner named Sam, in the worked examples. For now, just know that every folder name you see here is invented for practice.

---

Why bother with the command line at all?

A graphical file manager is wonderful for looking around. It is much weaker at repeating a task, describing a task to someone else, or doing a task on a machine that has no screen. Servers, build tools, and automated pipelines all speak in typed commands, because a typed command can be saved in a file, shared in a message, and run again tomorrow without anyone clicking anything.

There is also a quieter benefit. When you type ls notes, you have said, in a few characters, exactly which folder you mean. A mouse click on a window says the same thing only if you can see the window. Precision and repeatability are the real reasons professionals keep coming back to the terminal, and they are the reasons this course starts here.

None of this means graphical tools are bad. It means that being able to do both makes you more capable than being able to do only one.

---

Terminal, shell, and the program you are really talking to

Two words get blurred together early on, so let us separate them carefully.

The terminal is the window. It is a place that displays text and accepts keystrokes. Historically it was a physical screen-and-keyboard device; today it is an application on your computer.

The shell is the program running inside that window. Its job is to read the line you type, work out what you meant, start the right program, and show you what comes back. Common shells are bash and zsh. They differ in small comforts, but the ideas in this module are the same in both.

A useful picture: the terminal is a telephone handset, and the shell is the person who answers. You speak into the handset; the person understands you, arranges for the work to be done, and reports back. If you change the handset, you still reach the same kind of person.

The line of text that waits for you is called the prompt. It often ends with $ or %. In this course, when we show a command, we leave the prompt out so you can copy only what matters.

Common confusion: "My terminal crashed" usually means a program inside it stopped or got stuck, not that the window is broken. The shell is typically still there, waiting for the next line.

---

Command structure: program, options, arguments

Almost every line you type has three kinds of parts, in this order:

program-name  options  arguments

Here is a real one:

ls -l notes

Read it left to right as a sentence. ls is the program, a small tool whose job is to list what is inside a folder. -l is an option: it changes how the program behaves, here asking for a long listing with extra details. notes is an argument: it tells the program what to act on, here the folder named notes.

A short way to remember the difference is that options change how, and arguments say what. Options usually begin with a hyphen, and many programs accept several at once, either separately (-l -a) or joined (-la). Arguments are usually names of files or folders, but they can be other things depending on the program.

The pieces are separated by spaces, and that is the single most important mechanical fact of this module. The shell splits your line into words wherever it sees spaces. Keep that in mind; it returns when we reach quoting.

If you ever forget what a program accepts, many of them answer to:

ls --help

On some systems you can also read a longer manual page with man ls. You do not need to memorise options; you need to know how to look them up.

---

Where files live: the idea of a path

Every file and every folder has an address. That address is its path: a written route through the folders that leads to the item. Paths use / to separate one folder name from the next, so tidewatch/notes/day1.txt means "inside tidewatch, inside notes, the file day1.txt".

Why do we need paths at all? Because many files can have the same name in different places. Sam's project might have a summary.txt in notes and another in drafts. The folder route is what tells them apart.

There are two ways to write a route, and understanding the difference is the single most useful thing in this lesson.

---

Absolute paths: from the very top

An absolute path begins with a /. That leading slash means "start at the root of the whole filesystem and follow the route from there". Because it begins at a fixed starting point, an absolute path means the same thing no matter where you are standing when you use it.

/Users/sam/cli-practice/tidewatch/notes/day1.txt

On a Linux machine your home folder is usually under /home, for example /home/sam/...; on macOS it is under /Users. The idea is identical.

You can think of an absolute path like a full postal address, with country, city, street, and number. It works from anywhere.

Relative paths: from where you stand

A relative path does not begin with /. It starts from your current working directory: the folder the shell considers "here" right now. notes/day1.txt means "from here, go into notes, then find day1.txt".

A relative path is like giving directions to someone already standing in the building: "second door on the left." It is shorter and handier, but it only makes sense if you both agree where "here" is.

The consequence is important. The same relative path can point at different files depending on your current directory. If you are in tidewatch, then notes/day1.txt is one file; if you are somewhere else, that same text may point at nothing. When a command says "No such file or directory" and you are sure the file exists, the first suspect is almost always your location.

---

Finding out where you are: pwd

pwd

pwd stands for print working directory. It prints the absolute path of the folder the shell treats as "here". It takes no options in everyday use and has no side effects, so it is perfectly safe to run as often as you like.

If pwd prints /Users/sam/cli-practice/tidewatch, then the relative path notes/day1.txt means exactly /Users/sam/cli-practice/tidewatch/notes/day1.txt. Mentally add the two together and you have resolved the relative path by hand. Doing this addition out loud is the best habit you can form early.

---

The three shortcuts: ., .., and ~

Three tiny names do a lot of work, and each is something the system provides for you.

• . means the current directory, "here". It seems pointless until you need to say "this folder" to a command that insists on an argument.
• .. means the parent directory, the folder that contains "here". Chain them to climb: ../.. is two levels up.
• ~ means your home directory, the personal folder where your account keeps its files. The shell replaces ~ with the full path to home before the program ever sees it.

A small calculation shows how they combine. Suppose pwd shows /Users/sam/cli-practice/tidewatch/notes. Then .. is /Users/sam/cli-practice/tidewatch, and ../drafts is /Users/sam/cli-practice/tidewatch/drafts. And ~/cli-practice is /Users/sam/cli-practice no matter where you currently are.

Common confusion: ~ is not the root /. Root is the top of the entire filesystem; ~ is just your personal branch. They are very different places.

---

Moving, just enough to practise

The next module covers navigation properly, but you need one command now to try things out:

cd tidewatch

cd means change directory. It changes your current working directory, so every relative path afterwards starts from the new place. Typing cd .. goes up one level, and cd ~ or plain cd returns home. Combine cd with pwd and you have a loop: move, then check.

---

The filesystem is a tree

Picture a tree turned upside down. At the top is the single root /. From it branch folders; inside those folders sit more folders and, at the ends, files. There is exactly one root, and every item can be reached from it by exactly one straight route.

Here is the small part of the tree this course will grow, with Sam's home above it:

/
  Users/
    sam/
      cli-practice/
        tidewatch/
          notes/
          drafts/

Reading a path is walking down this picture. Reading .. is walking one step back up. If you ever feel lost, draw the three or four boxes around you; the sketch nearly always reveals the mistake.

Two different paths can end at the same place, for example ./notes and ../tidewatch/notes from inside tidewatch. That is fine. The important thing is that you know which place your command is aiming at.

---

Case sensitivity

On Linux and macOS terminals, as a rule, upper and lower case are different letters in names. Report.txt, report.txt, and REPORT.txt can all exist side by side as three separate files. (Some macOS setups are case-insensitive by default, which can hide this, but do not rely on it; write commands as if case matters, because on most Unix-style systems it does.)

The practical rule is simple: type names exactly as they appear, and prefer all-lowercase names for anything you create yourself. That removes a whole category of "but it is right there!" mistakes.

---

Spaces, quotes, and why they matter

Remember that the shell splits a line into words at spaces. That is perfect for separating a program from its arguments, but it causes trouble when a name itself contains a space.

Suppose a file is called tide notes.txt. If you type:

cat tide notes.txt

the shell hears two arguments, tide and notes.txt, and cat will look for two separate files. Quotes tell the shell "treat this as one word":

cat "tide notes.txt"

You can also use single quotes, or put a backslash before each space (tide\ notes.txt). Double quotes are the easiest to read.

One subtle point: inside quotes, ~ is not expanded. "~/cli-practice" is treated as a literal tilde character, not your home folder. Leave the tilde outside the quotes (~/"tide notes") or use "$HOME/cli-practice".

The easiest cure is prevention. When you create names, use snake_case (tide_notes.txt) or kebab-case (tide-notes.txt). Reserve quoting for names other people gave you.

---

Who is running these commands?

Everything you type runs as you, your user account. Soon we will see that every file has an owner and a set of permissions describing who may read or change it. For now, remember only this: the shell trusts you. It does not pause to ask "are you sure?" before doing most things, so a calm pace and a quick pwd before anything destructive are good insurance. We return to risky commands in a later module.

---

Common pitfalls, gathered in one place

• Wrong location. The command is right; you are standing in the wrong folder. Run pwd.
• Confusing absolute and relative. A leading / changes the meaning completely; /notes is a top-level folder, notes is something near you.
• Treating ~ like /. Home is not root.
• Unquoted spaces. One file looks like two arguments.
• Capital letters. Notes and notes are different names.
• Hunting for a prompt symbol. The $ or % is the shell's mark; you never type it.

---

Self-study checklist

Work through these with a terminal open and a sheet of paper.

• State, in your own words, how a terminal differs from a shell.
• Take ls -l notes and label the program, the option, and the argument. Then label ls -a ~.
• If pwd prints /home/sam/cli-practice/tidewatch, write the absolute path that drafts/plan.txt refers to.
• From that same location, write two different relative paths for /home/sam/cli-practice.
• Explain, in one sentence each, what ., .., and ~ mean.
• Draw a tiny tree with cli-practice, tidewatch, and notes, and mark where .. would take you from notes.
• Say why cat tide notes.txt fails and what fixes it.
• Explain why Notes and notes might refer to two different folders.

If any of these felt shaky, reread the matching section once, then try again without peeking.

Worked examples — Sam's first day at tidewatch

These five short stories follow Sam, who has just been handed the tidewatch coastal observation project. Type each command yourself in a terminal. Where a command's name is new (mkdir, touch), treat it as a setup step for now: the next module teaches directory building properly. Paths below assume a home folder of /Users/sam; yours will differ, and that is fine. Read the "interpretation" paragraphs carefully, because they are where the lesson sits.

---

Example A — Finding the starting point

Scene. Sam opens a fresh terminal and wants a quiet corner to practise in, so nothing important can be disturbed. Before doing anything, Sam asks the simplest question: where am I?

pwd
mkdir -p ~/cli-practice
cd ~/cli-practice
pwd

Expected outcome. The first pwd prints Sam's home folder, something like /Users/sam. The next two commands create the sandbox folder (if it is not already there) and step into it. The final pwd prints /Users/sam/cli-practice.

Interpretation. Notice that Sam used ~/cli-practice rather than typing the full home path. The shell replaced ~ with the home directory before mkdir and cd ever saw it. Also notice the rhythm: do something, then check with pwd. The check cost nothing and removed all doubt about where later relative paths would start.

Takeaway. pwd is a free, safe question. Ask it whenever you have just moved, or before you rely on a relative path.

---

Example B — One file, two ways to name it

Scene. The project lead has asked Sam to keep a daily note. Sam builds a first corner of the project and creates an empty note to practise naming.

cd ~/cli-practice
mkdir -p tidewatch/notes
touch tidewatch/notes/day1.txt
cd tidewatch
pwd
ls notes/day1.txt
ls /Users/sam/cli-practice/tidewatch/notes/day1.txt

Expected outcome. pwd prints /Users/sam/cli-practice/tidewatch. Both ls commands print the path they were given, which tells you the file exists and was found. (If your home path is not /Users/sam, use the path pwd showed you in the last line.)

Interpretation. notes/day1.txt is relative: the shell attaches it to the current directory, so it became /Users/sam/cli-practice/tidewatch/notes/day1.txt. The second command is the absolute version, which begins with / and therefore works from anywhere. Both name the same file. Now imagine Sam typed cd ~ and then repeated the relative command: ls notes/day1.txt would fail with "No such file or directory", because from home there is no notes folder. The absolute version would still succeed.

Takeaway. Relative paths are short but depend on where you stand; absolute paths are long but stand on their own. When a path "stops working", check your location first.

---

Example C — Walking with dots and tilde

Scene. Sam adds a second folder for early drafts and wants to hop between folders without retyping long paths.

cd ~/cli-practice/tidewatch
mkdir drafts
cd notes
pwd
cd ..
pwd
cd drafts
pwd
cd ../notes
pwd
cd ~
pwd
cd ~/cli-practice/tidewatch/drafts
pwd

Expected outcome. The pwd lines print, in order: .../tidewatch/notes, then .../tidewatch, then .../tidewatch/drafts, then .../tidewatch/notes again, then /Users/sam, then .../tidewatch/drafts once more.

Interpretation. Walk through the tree with a finger. From notes, .. climbs to tidewatch. From drafts, ../notes means "climb to the parent (tidewatch), then go down into notes", which lets Sam move sideways between sibling folders in one step. cd ~ jumps home from anywhere, and ~/cli-practice/tidewatch/drafts is an absolute-style route that begins at home. Every pwd confirmed the result, so Sam was never guessing.

Takeaway. .. is "one step up", ~ is "go home", and combining .. with a folder name lets you step sideways. Draw the tree, and the movement is easy to predict.

---

Example D — A name with a space

Scene. A colleague emails a file called tide log.txt, and Sam saves it into notes. Sam types a quick command to read it and gets an error that looks confusing.

cd ~/cli-practice/tidewatch/notes
touch "tide log.txt"
ls
cat tide log.txt
cat "tide log.txt"

Expected outcome. ls shows day1.txt and tide log.txt (some systems add quotes around the second name when listing). The first cat prints errors saying tide and log.txt do not exist. The second cat runs without errors; the file is empty, so it prints nothing.

Interpretation. Without quotes, the shell split the line at the space and handed cat two arguments: tide and log.txt. Neither file exists, so cat complained about both. Quotes told the shell "this is one word", so cat received a single argument and found the file. Sam decides the name is awkward and renames it later; for any file Sam creates, a name like tide_log.txt avoids the issue completely.

Takeaway. Spaces separate arguments, so names containing spaces need quotes. Better still, avoid spaces in names you create.

---

Example E — Case matters

Scene. Sam saves a quick reminder as Summary.txt in drafts, then tries to open it by typing the name in lowercase from habit.

cd ~/cli-practice/tidewatch/drafts
touch Summary.txt
ls
ls summary.txt
ls Summary.txt

Expected outcome. ls shows Summary.txt. On most Linux systems the second ls reports No such file or directory and the third succeeds. (On a macOS machine formatted case-insensitively, the lowercase attempt might appear to work. Do not rely on that behaviour.)

Interpretation. To a Unix-style system Summary.txt and summary.txt are different names, so the lowercase request looked for a file that was never created. Sam could create both without any conflict, which is exactly why mismatched capitals cause confusion on teams. The cure is a convention: Sam adopts all-lowercase names, such as summary.txt, from now on.

Takeaway. Type names exactly as they are written, and choose lowercase names yourself so there is nothing to remember.

---

Putting the five stories together

Across the day, Sam's tree became:

tidewatch/
  notes/
    day1.txt
    tide log.txt
  drafts/
    Summary.txt

Each example circled one idea: where am I (A), how do I name a place (B), how do I move between places (C), and how do I write names the shell will not misread (D and E). If you can narrate each story without looking, you have the module.