3  The Command Line

3.1 Understanding the Command Line

Most of the tools in this book are installed, configured, and often driven from the command line. The editors in Editors and Version Control each embed a terminal for the same reason. An afternoon here saves you guessing later.

3.1.1 What Is the Command Line?

The command line (also called terminal, shell, or console) is a text-based interface where you type commands for the computer to execute. Graphical interfaces let you point and click; the command line gives you more precise control through text commands.

Why bother, when we have modern GUIs?

Partly because you have no choice. Git, Docker, pip, conda and uv are command-line tools first, and their graphical wrappers cover a fraction of what they do — pip alone takes dozens of options for handling dependencies, versions, and install locations that no graphical installer exposes.

The better reason is that a command can be written down. Anything you type here can be saved in a script and run again next month, on someone else’s machine, in exactly the same order. A sequence of clicks leaves no such record, which is why so much of the reproducibility material later in this book assumes a terminal. Speed comes along as a side effect: installing five packages is one line rather than five wizards.

3.1.2 Getting Started with the Command Line

3.1.2.1 On Windows

Windows offers several options for command line interfaces:

  1. Command Prompt: Built into Windows, but limited in functionality
  2. PowerShell: A more capable alternative, also built in, and the default in Windows Terminal
  3. Windows Subsystem for Linux (WSL): A full Linux environment running inside Windows

Start with PowerShell, which is already there. Git Bash, installed with Git in Editors and Version Control, is the one to use when you’re following a tutorial written for macOS or Linux — see the note at the end of this chapter. WSL is the heavier option, worth installing when you want a genuine Linux environment rather than a Unix-style shell. To install it, open PowerShell as administrator and run:

wsl --install

This installs Ubuntu Linux by default. After installation, restart your computer and follow the setup prompts.

3.1.2.2 On macOS

The Terminal application comes pre-installed:

  1. Press Cmd+Space to open Spotlight search
  2. Type “Terminal” and press Enter

3.1.2.3 On Linux

Most Linux distributions come with a terminal emulator. Look for “Terminal” in your applications menu.

3.1.3 The Commands Worth Knowing

Open your terminal and try these:

3.1.3.2 Creating and Editing Files

You’ll usually reach for an editor instead, but three commands are worth recognising:

# Create an empty file
touch newfile.txt

# Display file contents
cat filename.txt

# Simple editor (press i to insert, Esc then :wq to save and quit)
vim filename.txt

touch makes an empty file, cat prints one to the screen, and vim edits one in place. vim is worth knowing only because it is what a server drops you into when something needs editing and nothing else is installed.

3.1.4 Package Managers

Most command line environments include package managers, which help install and update software. Think of package managers as app stores for your command line. Common ones include:

  • apt (Ubuntu/Debian Linux)
  • brew (macOS)
  • winget (Windows)

For example, on Ubuntu you might install Python using:

sudo apt update
sudo apt install python3

On macOS with Homebrew:

# Install Homebrew first if you don't have it
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Then install Python
brew install python

sudo grants temporary administrator privileges, the terminal equivalent of Windows asking “Do you want to allow this app to make changes to your device?”

That Homebrew line deserves a second look, because you will meet its shape often. curl downloads a file; the surrounding /bin/bash -c "$(...)" hands what came back straight to the shell and runs it. You are executing code from the internet without reading it first. For an installer published by the project itself — Homebrew here, uv and Docker later — this is the documented method and the risk is the same as running any installer you downloaded. For a one-liner you found in a forum answer, download it to a file, read it, then run it.

3.2 Three Constructs You’ll See Everywhere

Beyond navigating and installing, three pieces of shell syntax appear throughout the rest of this book. They look cryptic and mean something simple.

Redirection: > sends output to a file. By default a command prints its results to the screen. > diverts that into a file instead, replacing whatever was there:

# Instead of printing the package list, write it to a file
pip freeze > requirements.txt

# Two arrows appends rather than replacing
echo "one more line" >> notes.txt

This is why the environments chapter records a project’s packages with uv pip freeze > requirements.txt. The command doesn’t know about files at all — the shell captures its output and writes it.

Pipes: | sends output to another command. Where > writes to a file, | feeds one command’s output directly into the next as input, letting you chain small tools:

# List files, and pass that list to a search for ".csv"
ls | grep ".csv"

# Count the lines in a file
cat data.csv | wc -l

Each program does one job and knows nothing about the others, which is why small tools you can chain have outlasted most of the large ones.

Environment variables hold settings the shell passes to programs. These are named values that live in your shell session, and any program you launch can read them. PATH — the list of directories searched when you type a command name — is one you have already met:

# Show one variable (macOS/Linux/Git Bash)
echo $PATH

# Set one for this session
export API_KEY='abc123'
# The same two things in PowerShell
$env:PATH
$env:API_KEY = 'abc123'

Note the difference: Bash uses $NAME and export, PowerShell uses $env:NAME and plain assignment. Variables set this way last only until you close the terminal. This is the mechanism behind keeping passwords out of your code — Data Stores uses it for exactly that — and behind hosting platforms telling your application which port to listen on.

3.3 A Note on Windows Shells

Windows gives you three shells and they are not interchangeable, which is the source of a great deal of confusion when following tutorials.

  • PowerShell is the modern default and what Windows Terminal opens. Most of this book’s commands work here.
  • Git Bash ships with Git for Windows and gives you a Unix-style shell. Anything in this book written for macOS or Linux works in Git Bash, which makes it the safest choice when following a tutorial that assumes Unix.
  • Command Prompt (cmd.exe) is the legacy shell. It’s still around, and a few things differ — $(pwd) doesn’t expand, for instance (use %cd%).

If a command from a tutorial fails on Windows with a syntax error rather than a “not found” error, you are usually in the wrong shell rather than typing the wrong thing. Try it in Git Bash.

PowerShell has one more trap worth knowing now: && and || don’t work in Windows PowerShell 5.1, the version that ships with Windows. A; if ($?) { B } is the equivalent. PowerShell 7, installed separately, does support &&.

3.4 Conclusion

By the end of this chapter you should be able to:

  • Open a terminal on your operating system and tell which shell you’re in
  • Navigate the filesystem with pwd, ls, and cd without thinking about it
  • Create, inspect, and delete files and directories — and know that rm -r has no undo
  • Install software with your platform’s package manager
  • Recognise >, |, and $VARIABLE when a later chapter uses them without explanation

None of this needs to be memorised. cd, ls, and pwd become automatic within a week of use, and the rest you can look up. You mainly want to reach the point where a terminal window stops feeling like somewhere you might break something.

The next chapter installs the languages themselves.