Opening a terminal, and standing somewhere

95 min

Listen: this lesson as a conversation

Two hosts talk the lesson through. The voices are synthetic; the script was written from this lesson and checked against it, and asserts nothing the lesson does not.

In this lesson you will learn to

Open a POSIX shell on your own operating system, installing one first if you are on Windows, and say what you trusted in order to get it
Explain what the working directory is, and predict what a command will do before you press return
Run pwd, ls and cd with ~, . and .. to reach a directory you named in advance
Say why a command that worked last night fails this morning, and fix it without guessing

Everything you have done in the last two lessons was done by clicking. You found your home directory, you wrote out addresses, you turned on file extensions. All of it happened in a window somebody designed for you.

Now we are going to do the same things by typing, and the first thing to get straight is that this isn't a second computer. It's the same tree, the same directories, the same files. A file browser and a terminal are two windows onto one thing, and the fastest way to believe that is to put them side by side and watch them agree.

That arrangement isn't attributed to anybody. It is simply what makes the next hour work, so this lesson is built on it and you'll need both windows open. The commands themselves are the first handful of the set MIT's Missing Semester opens with; the rest arrives in the next two lessons.² Where the lesson tells you what goes wrong, that comes from Software Carpentry's shell lesson and its instructor notes, which are a long-running record of what actually goes wrong when this material is taught.¹

Getting a shell

A shell is a program that reads what you type, works out what you meant, and runs it. A terminal is the window the shell runs inside. People use the two words loosely and it rarely matters.

This course teaches a POSIX shell, which means bash or zsh. That's a choice, and it has a cost, so here's the reason before the instructions.

It's about where you can go next, not about which shell is better. The three free, full-length courses this one points you to next, Software Carpentry's shell lesson, MIT's Missing Semester, and the book at linuxcommand.org, all teach these commands, and so does every later Computing course on the Foval Core. Learn them and those doors are open. PowerShell has free full-length material of its own, published by Microsoft, so this is a choice about which door this course walks you through rather than a claim that only one exists.

On macOS, you already have one. Press Command and Space, type Terminal, and press return. You can also find it in Applications, then Utilities. The shell you get is zsh, which Apple has made the default for new accounts since 2019. On a Mac whose account is older than that you may get bash instead, and everything in this lesson works the same in either.

On Linux, you already have one too. On GNOME, Cinnamon and KDE, Control, Alt and T together opens it. Some desktops, XFCE among them, ship no shortcut at all, so look for Terminal in the applications menu. The shell is usually bash.

On Windows, you need to install one, and this is the first time this course asks you to install anything. The recommendation is Git for Windows, which includes a program called Git Bash: a bash shell that runs on Windows. It's small, it needs no restart, and it doesn't require anything to be switched off. The project describes it as a BASH emulation used to run Git from the command line, which undersells it: the shell you get is a real bash.⁴

Go to git-scm.com/install/windows. As of 18 September 2026, that page offers a 64-bit installer and an ARM64 installer, portable versions of both, and a package manager command. Take the standalone installer that matches your machine, and accept the defaults unless you know why you're changing one. When it finishes, Git Bash is in your Start menu.

If you don't know which machine you have, open Settings, then System, then About, and read the line marked System type. Almost every Windows PC is x64; ARM64 ones are still unusual and you'd probably know.

Before you install anything, name what you are trusting

You're trusting two parties, and it's worth saying them out loud, because this is the habit that the whole second half of this course is built on.

You're trusting the project, Git for Windows, not to ship something harmful. And you are trusting the route, the site you downloaded from, to be giving you what the project actually published rather than something a third party substituted.

So look at the address bar before you click download, and check it says git-scm.com. A search engine result that looks right and goes somewhere else is one of the standard ways this goes wrong, and lesson 9 takes the whole problem apart properly.

One thing this course will never tell you to do: turn off a security feature to get an exercise working. If Windows SmartScreen or macOS Gatekeeper stops you, that's information, and the answer is to find out why rather than to switch the guard off.

The Windows Subsystem for Linux exists, and it is the better long-term home. It gives you a real Linux rather than a bash running on Windows. It also needs more setting up than this lesson covers: you open PowerShell by right-clicking it and choosing Run as administrator, run wsl --install, restart the machine, then open Ubuntu from the Start menu and invent a Linux user name and password, which are new and are not your Windows ones. Your Windows files then live under /mnt/c rather than where the file browser shows them, so the side-by-side arrangement this lesson depends on needs setting up too. Microsoft's own documentation, checked on 18 September 2026, has all of it, and says the command needs Windows 10 version 2004 or later, or Windows 11.³

Take Git Bash today and come back to that when you want it. One thing worth noticing on the way past: the install asks to run as an administrator, which grants it powers an ordinary program doesn't have. That isn't a detail to wave through, and lesson 9 is about exactly what you hand over when you agree.

What `pwd` prints on Windows

In Git Bash, pwd prints /c/Users/you where File Explorer prints C:\Users\you. Lesson 2 taught you the second form, and both name the same directory: bash writes the drive as though it were the first directory under the root, and uses forward slashes throughout. Read them as the same address, because they are.

Under WSL it goes further. There pwd prints /home/you, which is a Linux home directory that has nothing in common with your Windows one, and your Windows files sit under /mnt/c. That is a real second tree, not a second spelling, which is the other reason this lesson recommends Git Bash first.

If you already know PowerShell, read this before you skip the install

PowerShell is a capable shell and it has two real advantages this course is giving up. It is already on the machine, which matters in a lesson that has just made installing software a thing you should stop and think about. And its pipelines carry structured objects rather than lines of text, which removes a whole class of bug that POSIX shells still have: no quoting accidents, no guessing where one field ends and the next begins.

What it does differently, and what will bite. ls, cat and pwd exist there as aliases for its own commands, and they mostly do what a POSIX user expects right up until they don't. Because the pipeline carries objects, the text-filtering habits lesson 6 teaches don't transfer. Windows writes paths with backslashes and PowerShell displays them that way, though it will accept forward slashes in its own commands, which is not the same as every program you call from it accepting them.

The middle case is the one that costs you. Some POSIX-shaped input fails loudly and helpfully: grep and touch simply aren't there, and PowerShell says so. The trouble is the command that half works. ls runs, prints something that looks near enough right, and hands the next command objects rather than lines, so a pipeline copied from a tutorial quietly does something you didn't ask for. A clean failure is easy to diagnose. A half-success isn't, and that is the reason this course asks Windows learners to install a bash rather than adapt.

Open both windows now

Put the two views side by side

Take 5 minutes and do not read on until both windows are open.

Open your terminal.
Open your file browser, and take it to your home directory, the one you wrote down in lesson 2.
Arrange them so you can see both at once. Half the screen each is fine.

Leave them like that for the rest of the lesson. Every command below is meant to be checked against the window next to it.

The prompt, and the one idea underneath it

Your terminal is showing you a line of text with a cursor after it. That is the prompt, and the shell prints it to say it is ready.

What's in it varies. A common shape is your user name, then the machine's name, then the directory you are standing in, then a $ or a %. Some are just $. You can change yours, people do, and none of it is load-bearing. The symbol at the end is the part to recognise: it means the shell is waiting for you rather than busy running something.

Now the idea that everything else in this course's terminal half rests on.

A shell is always standing in exactly one directory. That directory is called the working directory, and it persists: it stays whatever it is until something changes it, across every command you type.

Why does the shell need one? Lesson 2 gave you the answer without naming it. Most of the names you type are relative, and a relative name is not an address until something supplies the front of it. Documents isn't a place. Documents starting from /Users/you is a place. The shell holds one standing point and resolves every relative name against it, and that is the entire content of the idea.

Once you have it, a great many confusing things stop being confusing, and the biggest is this one: the same command is a different instruction depending on where you're standing.

Check yourself

Say in your own words why the shell has to keep a standing point at all. One sentence, as if to somebody who has never opened a terminal.

Show the answer

Something like: most of the names you type are partial, and a partial name isn't an address until something supplies the front of it, so the shell keeps one position and finishes every partial name with it.

If your sentence was about speed, or about the shell remembering where you were, try again. Neither is it. The working directory isn't a convenience; it's the thing that makes a short name mean anything.

The three commands

Type each of these and watch the window next to you.

pwd prints the working directory. It stands for "print working directory". Run it now. The absolute path it prints should be the one showing in your file browser.

ls lists what is in the working directory. Run it. Compare the names against the window next to you. If a directory is empty, ls prints nothing at all and hands you a fresh prompt, which is an answer rather than a failure.

Your two windows may not agree, and the disagreement is worth a minute. If lesson 3's hidden-items setting is still on, your file browser is showing you names that begin with a dot, and plain ls leaves them out. That isn't a dispute about what is there. It is two programs with different defaults about what is worth showing, and ls -a asks for the unfiltered list.

cd changes the working directory. cd Documents moves you into Documents, if there is one where you are standing. Run it, then run pwd again, and watch the two lines differ.

Check first, because this is where a lesson usually assumes something. Look at what ls just printed. If there is no Documents in the list, pick any directory name that is there and use it everywhere below instead. There are three ordinary reasons it might be missing: on Windows, OneDrive sometimes moves it, in which case ls shows a OneDrive entry and your Documents is inside that; on a Linux desktop set to another language it has another name; and a fresh WSL home directory starts out empty. None of those is a broken machine.

Three more names, which you met in lesson 2 and which now become things you type.

.. is the directory one level up. cd .. takes you back.

. is the directory you're standing in. cd . does nothing at all, which sounds useless. It stays useless until lesson 6, which shows you the one place where writing the dot changes whether a command runs.

~ is your home directory, whatever its full address happens to be. cd ~ takes you home from anywhere, and so does cd on its own, which is a small kindness you'd only discover by reading the manual. Lesson 5 is about reading the manual.

Predict first

You are standing in your home directory. You run cd Documents, then cd .., then cd Documents again, then cd ~. Where are you, and how many times did the working directory actually change?

Show the answer

You are at home, and it changed four times: into Documents, back to home, into Documents, back to home. Every one of those commands did something.

The point of the question is the second half of it. People expect cd .. and cd ~ to be the same when they are one level down, and they happen to be, here. Go two levels down and they part company: cd .. goes up one, and cd ~ goes all the way home regardless. Try it before you believe me, which is the only way anything in this lesson should be believed.

Tab completion, which is a check and not a shortcut

Type cd Doc and press the Tab key. If a directory starting with Doc is where you are standing, the shell finishes the name for you.

Everyone teaches this as a way to type less. That's true and it's the least interesting thing about it.

Tab completion can only complete something that exists. So when you type three letters, press Tab, and nothing happens, the shell has just told you something true and useful: there is no name starting with those letters here. Either you've got the name wrong, or you're not standing where you think you are.

That makes Tab the cheapest diagnostic in the terminal. Before you convince yourself a file has vanished, type the first few letters of its name and press Tab. Silence is evidence.

The same command, two answers

This next case teaches the working directory better than any definition can.

Stand in your home directory and run ls Documents. You get a listing.

Predict first

Now run cd Documents, so you're inside it, and get ready to type exactly the same command again: ls Documents. Before you press return, write down what you expect to see.

Show the answer

Most people expect the same listing, because the command has not changed by a single character. What you get is an error.

The command didn't change. Where it was asked from did, and that turns out to be half of what a command means.

Run it.

You get an error. On the machine I am writing this on, it reads:

ls: Documents: No such file or directory

The wording varies slightly between systems; the phrase "No such file or directory" is the common part.⁵

Nothing about the command changed. Not a character. What changed is where it was asked from, and Documents is a relative name, so from inside Documents it means a Documents inside Documents, which does not exist.

Check yourself

You are inside Documents and you want that listing again without leaving. At least two commands will do it. How many can you find?

Show the answer

ls on its own is the plain answer. With no argument it lists the working directory, which is where you are.

ls . does exactly the same thing, and that is the honest note to make about the single dot: here it buys you nothing at all. Keep it in your pocket anyway. Lesson 6 shows you the one place where writing the dot is the difference between a command running and not running.

ls ~/Documents also works, and it works from anywhere at all, because it is an absolute address written with the ~ shorthand. That is the trade lesson 2 described: the relative form is shorter and depends on where you stand, the absolute form is longer and doesn't.

The command that worked last night

Now the version of this that will actually happen to you, and it is worth recognising before it does rather than after.

You spend an evening working in a directory. Everything runs. You close the terminal and go to bed.

In the morning you open a terminal, type the same command out of your notes, and it fails.

A terminal opened the way this lesson opened yours starts in your home directory. It doesn't remember last night. The command in your notes was relative, it was correct from where you were standing yesterday, and this morning you're standing somewhere else.

Some routes behave differently, and it's worth knowing which: right-clicking a folder and choosing to open a terminal there starts you in that folder, and so does the terminal built into a code editor. So the rule to carry is the more general one. A new terminal starts wherever it was told to, and that is almost never where you were last night. pwd is how you find out rather than assume.

The fix takes two seconds once you know: run pwd to find out where you actually are, then cd to where you meant to be, then run the command again. The habit worth building is smaller still. When a command fails and you cannot see why, run pwd first. It's free, it's instant, and it settles the commonest cause before you start looking for complicated ones.

This isn't a beginner's mistake that you'll grow out of. It catches everybody, and it is the single most common reason a set of instructions that worked for the person who wrote them does not work for you.

What people get wrong

"The terminal is a different computer." It's a different window onto the same machine. Make a folder with the mouse, then run ls, and there it is. Rename it in the file browser and ls reports the new name. If the two windows ever disagree, one of them needs refreshing, and neither of them is lying.

"The terminal is for experts." The curriculum this lesson leans on teaches these commands to working scientists who are not computer scientists, and its stated prerequisite is that you recognise the word "file" and either "directory" or "folder".¹ That is lesson 2's entry requirement, which you already met.

"Typing is faster than clicking." For what you've done so far, it usually isn't, and I'm not going to pretend otherwise. The argument for the terminal isn't speed, and it isn't yet in front of you. Lesson 6 makes it, and it is about doing things the mouse cannot do at all.

"cd with no argument is an error." It takes you home. There are a number of small behaviours like that, and the way you find them is by reading what the command says about itself, which is lesson 5.

"Tab completion is a shortcut." It's a check that happens to save typing. Treating it as a check changes what you do when it stays silent.

"If the command is right, it will work anywhere." The whole lesson is the answer to that one.

Practice

Three directories, predicted before you arrive

Take 20 minutes. Keep both windows visible throughout. Write your predictions down before you press return, because a prediction you only thought is a prediction you can revise afterwards without noticing.

Choose three directories on your machine, in advance, and write down their names. Pick ones that are at different depths.
Get to the first one using an absolute path, the full address starting at the root. Before you press return, write down what you expect pwd to print. Then run cd, then run pwd, and compare.
Get to the second one using a relative path from where you now are. Work out the path on paper first, using .. if you need to go up before you come down. Predict, then run, then compare.
Get to the third one using .. at least twice. Predict, then run, then compare.
Every time you arrived, check the file browser window: take it to the same directory and confirm the two agree.
Now get home twice: once with cd ~, and once with cd on its own and nothing after it. Run pwd after each. Write down whether they did the same thing, and what that tells you about reading a manual rather than guessing.
Where you got a prediction wrong, write one sentence saying what you had assumed. That sentence is worth more than the four you got right.

Close it and open it again

Take 5 minutes, and do this one straight after the exercise above, while you are still somewhere deep in the tree.

Run pwd and write down where you are.
Close the terminal window completely. Open a new one.
Before running anything, predict what pwd will print now.
Run pwd. Then write one sentence explaining the result to somebody who has not taken this lesson.

Connections

Lesson 2 gave you absolute and relative paths as things to write down. This lesson made you type them, which is the version that sticks, and it added the piece lesson 2 couldn't have: the standing point that a relative path is relative to.

Lesson 3 gave you plain text, and you will need it in the next lesson, because lesson 5 has you save a file called hello.py and run it. A file that's nearly plain text will waste your evening.

Lesson 5 takes what you have just typed and teaches you to read it as a grammar rather than a spell: which word is the program, which words are the arguments, which are the flags. Then it teaches the most useful skill in this half of the course, which is telling from an error message alone whether the fault is where you are standing, the name of the program, or the program itself.

If you go on to the Core's Python course in Term 6, this lesson and the next are the ones it assumes. The thing it needs you to be able to do is exactly the exercise lesson 5 ends on.

Go deeper

Software Carpentry, The Unix Shell, episodes 1 and 2. Free, CC BY licensed, and the version of this material that has been tested on the most people. If any part of this lesson went too fast, that is where to slow it down.
MIT, The Missing Semester of Your CS Education, lecture 1. Written for computer science undergraduates, so it moves quickly and assumes you can program. Worth it once you are comfortable, and it is where lessons 5 and 6 take their scope from.
The Linux Command Line, a full-length book on the shell, free to download as a PDF under a Creative Commons licence. It goes far past where this course stops. Named here so you know it exists; this course hasn't worked through it and makes no claim about any particular chapter.

Sources

Software Carpentry, "The Unix Shell" (shell-novice), swcarpentry.github.io/shell-novice, CC BY 4.0. Lesson homepage, episode 2 and the instructor notes read in full. Supplies the side-by-side file browser and terminal as an instructional device, the stated prerequisite quoted again here from lesson 2, the pwd, ls, cd, ~, . and .. set, and tab completion.
MIT, "The Missing Semester of Your CS Education", missing.csail.mit.edu, CC BY-NC-SA. Homepage and the 2020 edition's lecture 1 notes read in full. Supplies the scope of commands this lesson and the next two draw on, and the framing of a command as a program handed some words.
Microsoft, "Install WSL", learn.microsoft.com/windows/wsl/install. Read 18 September 2026. Supplies the single install command, the requirement of Windows 10 version 2004 or later or Windows 11, the default Ubuntu distribution, and the restart.
Git for Windows, git-scm.com/install/windows and gitforwindows.org. Read 18 September 2026. Supplies what the Windows download page offers on that date, and the project's own description of Git Bash as a BASH emulation used to run Git from the command line.
Checked on the machine this lesson was written on, macOS 26, September 2026: the default shell is zsh; ls Documents run from inside Documents returns ls: Documents: No such file or directory; a newly opened terminal reports the home directory from pwd.

Check your understanding

This lesson has a 6-question quiz. Pass it and the questions come back on a schedule in Review, so what you learned stays learned. Your progress is saved in your browser; no account needed.

Open this lesson in the app