Module 1: The Terminal and the File System

3. Your terminal on macOS, Linux, and Windows (WSL)

Next →

Description

By the end of this lesson you will be able to open the right terminal on whatever operating system is in front of you — macOS, Linux, or Windows — and, if you use Windows, you will have WSL2 with Ubuntu installed and working, with a command that confirms which shell is running underneath that window. This is not a cosmetic detail: it is the difference between following the rest of this guide without friction or fighting a terminal that does not speak the same language as the examples.

This matters outside the classroom. The vast majority of the world's servers — where the code you write ends up living once it moves from your machine to production — run Linux. If your work computer is Windows and your only terminal is PowerShell or Command Prompt, every ls, grep, or chmod command you learn in this course will not work on your own machine: you will end up mentally translating between two different worlds, or copying commands that fail without you understanding why. Solving this now, before you type your first real command, saves you weeks of that silent friction.

Connection to the module: the previous lesson gave you the vocabulary — terminal, shell, prompt, console — and showed you that bash and zsh are different shells with different histories. This lesson brings that vocabulary down to your actual machine: which window you open, and in Windows's case, what extra piece you need to install so that window speaks the same language as the rest of the guide.

One terminal, three different doors into the same language

Think of three office buildings that have exactly the same layout inside — the same hallways, the same meeting rooms — but each one has the entrance in a different spot on the facade. In one the door is on the left, in another it is in the center, in the third you have to ring a bell before it opens. Once you are inside, it does not matter which door you came through: the building is the same.

Something similar happens with the terminal. bash and zsh — the shells you already know from the previous lesson — behave the same regardless of which application you use to open them. What changes from one operating system to another is the door: the application you have to open to reach that shell.

On macOS, the door is already installed out of the box: it is called Terminal.app and lives in Applications → Utilities. The fastest way to open it is Cmd+Space to bring up Spotlight, type "Terminal," and press Enter. Since macOS Catalina (2019), the shell that starts by default is zsh, just as you saw in the previous lesson. Terminal.app is enough for everything you need in this guide, but it is not the only door: iTerm2 is a free, widely used alternative that adds split panes, search within the history, and configurable profiles; Warp is a more recent option that adds smart autocompletion and reusable command blocks. Neither is required — install them later if you feel Terminal.app is not enough for you, not before.

On Linux, the door depends on the desktop environment you have installed, because Linux does not have a single "official" terminal: GNOME (the default desktop on Ubuntu and Fedora Workstation) ships GNOME Terminal; KDE Plasma (the desktop on Kubuntu) ships Konsole. In either case, searching "terminal" in the application launcher finds it, and on Ubuntu with GNOME the shortcut Ctrl+Alt+T opens it directly. If instead you connect to a Linux server with no graphical interface — something you are going to do in module 5 of this guide — there is no door to look for: you are already inside a terminal from the moment you connect.

On Windows is where the analogy breaks, and for a real reason: Windows does not run Linux underneath, so there is no native "door" into bash or zsh. PowerShell and Command Prompt (cmd.exe) are legitimate shells, but they speak a different language — different syntax, different philosophy, different commands — from the one you are going to learn in this guide and the one you are going to find on any Linux server. The solution this guide recommends is WSL2 (Windows Subsystem for Linux, version 2): a piece of Windows that runs a real Linux kernel inside a lightweight virtual machine integrated into the system. With WSL2 installed, you open a terminal that runs real Ubuntu, with real bash, with the same commands you are going to use for the rest of this guide.

Worked example

If you do not use Windows, you can still read this example: it helps you understand what awaits your Windows-using classmates, and you are going to need it the day you have to install it on a new machine.

Step 1. Open PowerShell as administrator: search "PowerShell" in the Start menu, right-click the result, and choose "Run as administrator."

Step 2. Run a single command:

wsl --install

This command does three things for you: it enables the Windows features WSL needs, downloads and installs the Linux kernel, and downloads Ubuntu as the default distribution. You do not need to choose anything else.

What to expect: a progress bar downloading components, and at the end, a message asking you to restart your computer.

Step 3. Restart. When the machine comes back on, Ubuntu opens automatically (or find it by typing "Ubuntu" in the Start menu) and asks you to create a Linux username and password — these are independent from your Windows account, and the password does not show on screen while you type it (that is normal, not an error).

Step 4. Confirm that version 2 got installed, not version 1 (WSL1 exists, but it is a more limited compatibility mode you do not care about for this guide). From PowerShell:

wsl -l -v

What to expect:

  NAME      STATE           VERSION
* Ubuntu    Running         2

The asterisk marks the default distribution, and the VERSION column showing 2 confirms you are running WSL2 and not version 1. From here on, whenever you need a Linux terminal on Windows, open Ubuntu directly or, better, install Windows Terminal (comes preinstalled on Windows 11 and installs free from the Microsoft Store on Windows 10) and pick the Ubuntu tab from its dropdown menu.

Why this guide recommends WSL2 instead of PowerShell, CMD, or Git Bash

It is worth saying this honestly, with what you gain and what you lose, instead of just telling you what to install.

What you gain with WSL2: a real Linux kernel, not an imitation. Tools like grep, find, or chmod behave exactly the same as on a production Linux server, because it is the same software, not a rewrite. This matters because the goal of this guide is not for you to memorize commands for one specific operating system: it is for you to know how to navigate any Linux machine, which is where you are going to end up spending most of your time as a developer. Git Bash — a popular alternative on Windows — gives you a similar feeling because it includes versions of Unix commands, but it runs on top of an emulation layer (MinGW) that translates those commands to the Windows world underneath; most of the time it works, but subtle differences show up right in the cases where you most need them not to (file permissions, paths, background processes). PowerShell, for its part, is not an imitation of anything — it is a modern, powerful shell in its own right, but it works with .NET objects instead of plain text, a different philosophy from the one you are going to study in module 3 of this guide. Learning it is worthwhile if you work in a pure Windows environment, but it is not what this guide teaches.

What you lose with WSL2: seamless integration with the rest of Windows. Your WSL files live in a Linux filesystem separate from Windows's; to reach your Windows files from inside WSL, you cross through /mnt/c/, and not every Windows graphical application opens files that live on the Linux side directly. It is a real cost, not an empty warning — but it is a small cost compared to having a development environment that matches almost any server you are going to connect to.

Checking which shell you have running: echo $SHELL

Regardless of the operating system, the same command tells you which shell you have assigned as your login shell:

echo $SHELL

What to expect on each system:

# macOS (Catalina onward)
/bin/zsh

# Linux (most distributions), and Ubuntu inside WSL2
/bin/bash

One precise detail worth being clear on: $SHELL does not always reflect the shell you are using at this exact moment, but the one the system assigned you as your login shell. If, at some point inside a bash session, you type zsh to launch zsh manually, $SHELL is going to keep showing /bin/bash until you close that session, because the variable gets set at login, not on every command you run. To know which process is interpreting your commands right now, on any system, there is ps -p $$ — but that is more detail than you need today; echo $SHELL is enough to confirm your terminal is running the right shell.

How operating-system differences will get marked for the rest of the guide

From here on, almost every command in this guide works without changes across all three cases: the macOS terminal, the Linux terminal, and the Ubuntu terminal inside WSL2 on Windows, because all three run real bash or zsh. When a specific command does change between systems — something infrequent, but that is going to happen at some point, especially in module 4 with permissions and processes — you are going to see it explicitly marked like this:

macOS/Linux: command-a Windows (WSL): command-b

If you do not see that mark on an example, it is because the command is identical in all three cases and there is nothing to distinguish.

Common mistakes

Thinking WSL2 is a heavy virtual machine, like installing VirtualBox with a full Ubuntu desktop. What happens: someone avoids installing WSL2 expecting a long process, several gigabytes of download, and a full Linux desktop window starting up separately, as if it were VirtualBox or VMware. Why it happens: WSL2 uses a different virtualization architecture, integrated into the Windows kernel, with no desktop interface of its own — it is a terminal, not a full operating system with its own graphical desktop. How to spot it: if after wsl --install and the restart you expect a full Ubuntu desktop window to appear instead of a terminal, that is a mismatch in expectations, not an installation error. How to fix it: what opens is a terminal window with a Linux prompt, exactly as if you had SSHed into a real Ubuntu server — that is all you need from WSL2 for this guide.

Continuing to use Git Bash or Command Prompt for the rest of the guide "because it was already installed." What happens: some commands in this guide seem to work in Git Bash, but produce results subtly different from what the text describes — file permissions that look strange, or a permission change that does not actually apply. Why it happens: Git Bash translates those commands to the Windows world underneath, and that translation is not perfect right in the cases that depend on Linux-specific concepts. How to spot it: a command's output does not match what this guide shows in "What to expect," even though the command did not throw an error. How to fix it: switch to the Ubuntu terminal inside WSL2 before continuing; you do not need to uninstall Git Bash, just stop using it to follow this guide.

After installing WSL2, still opening Command Prompt (cmd.exe) out of habit, instead of the Ubuntu terminal. What happens: you installed WSL2 correctly, but you keep typing bash commands into a cmd.exe window, which does not understand them. How to spot it: the prompt looks like C:\Users\your-name> instead of something like your-user@your-machine:~$. How to fix it: open Windows Terminal and choose the "Ubuntu" tab or profile from its dropdown menu, or simply type wsl inside any Windows window to drop directly into your installed Ubuntu.

Exercises

Exercise 1

Open the terminal that matches your operating system without looking up the steps online (use what you learned in this lesson) and run echo $SHELL. Write down the exact result.

See solution

There is no single correct result — it depends on your system:

  • macOS (Catalina onward): /bin/zsh
  • Linux (most distributions) or Ubuntu inside WSL2: /bin/bash

Why it works: $SHELL is an environment variable the system sets with the path to your login shell; on macOS that value switched to zsh in 2019, and on Linux — including Ubuntu inside WSL — it is still almost always bash by default.

Exercise 2

Explain in your own words, without copying the lesson's text, why this guide prefers WSL2 over PowerShell or Git Bash for following its steps on Windows. Mention at least one real advantage and one real disadvantage.

See solution

A complete answer mentions: WSL2 runs a real Linux kernel, so commands behave exactly like on a production Linux server, unlike Git Bash, which emulates those commands on top of Windows and can differ in specific cases (permissions, paths, processes). The real disadvantage is that WSL2 lives in a filesystem separate from Windows's, so crossing between both worlds — for example, to open a WSL file with a Windows graphical application — requires extra steps, like going through /mnt/c/.

Why it works: the decision is not "WSL2 is perfect," it is "the cost of WSL2 is smaller than the cost of learning commands that later do not match those of a real Linux server."

Exercise 3

If you use Windows: install WSL2 following this lesson's steps and confirm with wsl -l -v that the VERSION column shows 2. If you do not use Windows: ask someone who does use Windows to run that command and compare their output with what this lesson shows.

See solution

The expected output has this shape, with the asterisk marking the default distribution:

  NAME      STATE           VERSION
* Ubuntu    Running         2

If the VERSION column shows 1 instead of 2, the distribution got installed in the older compatibility mode; it can be migrated with wsl --set-version Ubuntu 2 from PowerShell.

Why it works: wsl -l -v (list, verbose) is the command Microsoft's own documentation recommends for confirming which WSL version each installed distribution is running, without having to guess from behavior.

Exercise 4

Before continuing with the rest of this guide: write down the exact name of the terminal you are going to use from here on, on your own machine (for example, "Terminal.app on macOS," "GNOME Terminal on Ubuntu Desktop," or "Ubuntu inside Windows Terminal, via WSL2").

See solution

There is no single correct answer — the grading criterion is different: whatever terminal you wrote down has to run real bash or zsh. If you use Windows and wrote down "PowerShell" or "Command Prompt," go back to the WSL2 installation section before continuing: from the next lesson on, this guide assumes you have a real Unix shell available.

Why it works: deciding this in writing, before moving on, prevents this lesson's most common mistake — continuing to use, out of habit, a terminal that does not speak the same language as the rest of the course.

Summary and next step

You now have an open terminal running a real Unix shell, regardless of whether your system is macOS, Linux, or Windows with WSL2, and you know how to confirm which one with a single command. That is the silent prerequisite this module's first lesson talked about: without this solved, every new command you learn becomes a source of doubt about whether the problem is the command or your environment.

Before moving on you should be able to open your terminal without thinking about it — without looking up the steps again — and say from memory which shell you have running underneath.

What comes next is the grammar of everything you are going to type in that terminal from here on: the universal structure shared by absolutely every command, no matter which one. That structure is the next lesson.

Resources

← Previous2. What is a shell and why the terminal still winsNext →4. The anatomy of a command: flags and arguments