Appendix 0 Part 1: Terminal and CLI Foundations

March 2026 (7751 Words, 44 Minutes)

1. Why This Appendix Exists

If you have ever felt lost when an instructor says “open a terminal and type this command,” this appendix is for you.

This course uses the terminal from day one. In Lecture 1, you will install Git, clone repositories, set up Python, and run your first programs – all through the terminal. Those instructions assume you already know what a terminal is, how to navigate folders, and how to read command syntax.

If you come from a non-Computer Science background, that assumption might not hold. And that is completely fine. Many professional developers started exactly where you are now.

By the end of this appendix, you will:

• Understand what a terminal is and why developers use it
• Know the difference between a terminal application, a shell, and an operating system
• Be able to navigate your file system using text commands
• Read and understand command syntax like git commit -m "my message"
• Know what PATH and environment variables are (and fix “command not found” errors)
• Understand what a program actually is at a basic level
• See why automation through scripting is a core skill in software engineering

This is pre-course reading. Work through it at your own pace before or alongside Lecture 1.

2. What Is a Terminal?

2.1 The Terminal as a Text Conversation with Your Computer

A terminal is a text-based interface where you type commands and the computer responds with text.

Think of it like a chat conversation:

You:       "Show me all files in this folder"
Computer:  "document.txt  photo.jpg  notes.md"

You:       "Create a new folder called 'project'"
Computer:  (creates the folder, says nothing -- silence means success)

You:       "Move into that folder"
Computer:  (moves you there, updates the prompt to show your new location)

In practice, the actual commands look like this:

$ ls
document.txt  photo.jpg  notes.md

$ mkdir project

$ cd project

The $ sign is the prompt – it means “the terminal is ready for your next command.” You do not type the $ yourself.

Every time you click a button in a graphical application, the application runs a command behind the scenes. The terminal lets you run those commands directly, without the graphical middleman.

Sound familiar? If you have ever used ChatGPT, Claude, or GitHub Copilot, you already know what a text conversation with a computer feels like. In fact, AI assistants are now entering the terminal itself – tools like GitHub Copilot CLI let you describe what you want in natural language, and the AI translates it into the right terminal command for you. You saw “GitHub Copilot CLI” in the VS Code terminal dropdown (Section 4.3) – that is exactly this.

So why bother learning terminal commands at all if AI can write them for you? For the same reason you learn math even though calculators exist:

• You need to understand what the AI suggests before you blindly run it. A wrong terminal command can delete files, overwrite work, or break your project.
• You need to verify and debug when things go wrong. The AI does not always get it right, and when it does not, you need to read the error message and know what it means.
• You need mental models of how the system works – PATH, shells, file permissions – to ask the AI good questions in the first place.

AI makes the terminal more accessible than ever. But it does not replace understanding – it amplifies it. Throughout this course, you will use AI tools alongside terminal skills, and you will see how much more effective the combination is than either one alone.

2.2 A Brief History: From Physical Terminals to Software

In the 1960s and 1970s, a “terminal” was a physical device – a keyboard and a screen (or even a printer) connected to a large central computer. Users would type commands, and the computer would send text back to their screen.

Today, the physical terminals are gone, but the concept survived as terminal emulators – software programs that simulate that same text-based conversation. When people say “open a terminal,” they mean opening one of these programs.

This is not outdated technology. It is the foundation that all modern computing is built on. Servers that run websites, cloud infrastructure, automated testing pipelines, deployment systems – they all run through text commands. Every professional software developer, system administrator, data scientist, and DevOps engineer uses the terminal daily.

2.3 Why Do Developers Still Use the Terminal?

Six practical reasons:

1. Speed – typing mkdir project && cd project && git init takes 3 seconds. Doing the same with clicks takes 30 seconds and many windows.
2. Automation – you can save commands in a file (a “script”) and run them again. You cannot save a sequence of mouse clicks.
3. Precision – a command does exactly what you tell it. GUIs sometimes hide options or make assumptions.
4. Reproducibility – you can share a command with a colleague by pasting text. You cannot paste a sequence of clicks.
5. Remote access – servers rarely have graphical interfaces. The terminal is the only way to interact with them.
6. Tool ecosystem – professional tools like Git, Python package managers (uv, pip), linters (ruff), and test runners (pytest) are designed for the terminal first. The graphical buttons you see in IDEs like VS Code are just wrappers around these terminal commands.

This last point is especially important for this course. Software engineering is not just about writing code – it is about understanding the ecosystem and infrastructure that surrounds code: version control, dependency management, automated testing, code quality checks, continuous integration, and deployment. All of these live in the terminal. When you understand the terminal, you understand how the entire software development pipeline works – not just the code editor in the middle.

That is why this course starts here: not with a programming language, but with the tools and workflows that every professional software project depends on.

flowchart LR
    subgraph GUI["GUI Workflow"]
        A1[Open File Explorer] --> A2[Navigate to folder]
        A2 --> A3[Right-click → New Folder]
        A3 --> A4[Type folder name]
        A4 --> A5[Open folder]
        A5 --> A6[Right-click → New File]
        A6 --> A7[Type file name]
    end

    subgraph CLI["Terminal Workflow"]
        B1["mkdir project && cd project && touch README.md"]
    end

    style GUI fill:#E8E8E8,stroke:#818390
    style CLI fill:#d8d6e8,stroke:#5A56A1

The GUI workflow requires 7 steps with mouse navigation. The terminal workflow is a single line.

3. Why Does the Terminal Look Different on Every Computer?

3.1 Operating Systems and Their Default Terminals

Each operating system ships with different terminal software and uses a different shell (the language the terminal speaks). This is why commands that work on your friend’s Mac might not work on your Windows PC.

Important: “Terminal” and “shell” are not the same thing, even though people (and even some software names!) use these words interchangeably. The terminal is the window; the shell is the language running inside it. This confusion is so common that we explain it in detail in Section 3.2 below. For now, notice that the table below separates “Terminal App” and “Shell” into different columns – they are genuinely different things.

Notice how even the prompt symbol differs: PowerShell uses >, zsh uses %, and bash uses $. This is cosmetic – they all serve the same purpose: “I am ready for your next command.”

3.2 The Terminal Application vs. The Shell

This is a distinction that confuses many beginners, but it is important:

• The terminal application is the window you see on screen. It handles text display, colors, fonts, scrolling, and copy/paste.
• The shell is the program running inside that window. It interprets the commands you type and talks to the operating system.

An analogy: the terminal is the phone (the device), and the shell is the language you speak on the phone. You can use the same phone to speak German or English. Similarly, you can use the same terminal window to run different shells.

flowchart TB
    A["👤 You (typing commands)"] --> B["Terminal Application\n(Windows Terminal, Terminal.app, GNOME Terminal)"]
    B --> C["Shell\n(bash, zsh, PowerShell)"]
    C --> D["Operating System\n(file system, programs, hardware)"]

    style A fill:#d4eaf7,stroke:#88BEE7
    style B fill:#E8E8E8,stroke:#818390
    style C fill:#d8d6e8,stroke:#5A56A1
    style D fill:#e4d3e0,stroke:#972982

When someone says “open bash,” they mean “open a terminal application that is running the bash shell.” When someone says “open PowerShell,” they mean the same thing but with PowerShell as the shell.

Why is this so confusing? Because some programs blur the line in their names. “PowerShell” is both a shell (the language) and a terminal application (the blue window). “Git Bash” is a terminal application that runs the bash shell. “Windows Terminal” is a terminal application that can run PowerShell, Command Prompt, or bash. The naming is inconsistent, which is why understanding the underlying distinction matters more than memorizing product names.

4. Multiple Terminals on the Same Computer

4.1 Windows: PowerShell, Command Prompt, Git Bash, and WSL

Windows is the most confusing platform because it has the most options. Here is what each one is:

Command Prompt (cmd.exe) – The oldest Windows terminal, dating back to the 1980s. It uses its own command syntax that is different from bash. Commands like dir instead of ls, type instead of cat. You will rarely need this.

PowerShell – The modern Windows default. More powerful than Command Prompt, but uses its own syntax that differs from bash/zsh. For example, Get-ChildItem instead of ls (though ls works as an alias). PowerShell is what opens when you launch Windows Terminal.

Git Bash – Installed automatically when you install Git for Windows. It provides a bash shell on Windows, so commands like ls, cd, cat, grep work the same as on Linux and macOS. This is what we recommend for this course because the vast majority of tutorials, Stack Overflow answers, and documentation use bash syntax.

WSL (Windows Subsystem for Linux) – A full Linux system running inside Windows. This is an advanced option. You do not need it for this course, but it exists if you want a complete Linux experience without dual-booting.

In this course, use either Git Bash or the VS Code integrated terminal (configured to use Git Bash). This way, all commands in the lectures and exercises will work for you regardless of your operating system.

4.2 macOS and Linux: Terminal Options

macOS: The built-in Terminal.app with zsh works perfectly. Some developers prefer iTerm2 (a third-party terminal with more features), but it is not necessary.

Linux: The default terminal (GNOME Terminal on Ubuntu, Konsole on KDE) with bash works out of the box. No configuration needed.

On both platforms, you can also use the VS Code integrated terminal, which runs whatever shell is your system default.

4.3 The VS Code Terminal: One Terminal to Rule Them All

VS Code has a built-in terminal that you will use extensively in this course. It appears at the bottom of the VS Code window.

How to open it:

• Press Ctrl+` (backtick, the key above Tab) on Windows/Linux
• Press Cmd+` on macOS
• Or go to View → Terminal in the menu bar

4.3.1 What Is Happening Inside the VS Code Terminal?

The VS Code terminal is a terminal application built into VS Code. Just like Windows Terminal or GNOME Terminal, it needs a shell running inside it. VS Code detects which shells are installed on your system and lets you choose which one to use.

When you click the dropdown arrow (▾) next to the + button in the terminal panel, you see a list of available options. On a typical Windows system, this might include:

The key insight: Every option in this list opens the same terminal window but with a different shell running inside it. This is the terminal vs. shell distinction in action. You can even have multiple terminal tabs open side by side, each running a different shell.

4.3.2 Multiple Terminal Tabs

Notice the bottom of the terminal panel shows tabs like “pwsh” (PowerShell) and “bash”. Each tab is a separate terminal session running its own shell. You can:

• Create a new tab: Click + (uses the default shell) or use the dropdown to pick a specific shell
• Switch between tabs: Click the tab name at the bottom
• Close a tab: Click the trash can icon
• Split the view: Click the split icon to see two terminals side by side

4.3.3 Setting Your Default Shell

If you want VS Code to always open Git Bash instead of PowerShell:

1. Press Ctrl+Shift+P (Command Palette)
2. Type “Terminal: Select Default Profile”
3. Choose “Git Bash”

From now on, every new terminal in VS Code will use Git Bash.

Try this now:

1. Open VS Code and press Ctrl+` to open the terminal
2. Look at the bottom of the terminal panel – what shell is running? (It shows “pwsh” for PowerShell or “bash” for Git Bash)
3. Click the dropdown arrow next to the + button – see the list of available shells
4. Open a Git Bash terminal from the dropdown
5. Now you have two tabs at the bottom. Try typing echo $SHELL in the bash tab and echo $PSVersionTable in the PowerShell tab – different shells, different commands, same VS Code window
6. Set Git Bash as your default (Ctrl+Shift+P → “Terminal: Select Default Profile” → Git Bash)

For more on VS Code setup, see Lecture 1, Section 7: IDEs.

5. Bash vs. Zsh: What Is the Difference?

5.1 What Both Have in Common

Bash and zsh are both Unix shells. They understand the same core commands: cd, ls, mkdir, rm, cat, echo, grep, chmod, export, and hundreds more. If you learn bash, you effectively know zsh too (and vice versa) for everyday use.

Both are available on Linux and macOS. Both are available on Windows through Git Bash (bash) or WSL (either).

5.2 Key Differences for Beginners

5.3 Which Shell Should You Use?

Use whatever your system gives you. The differences only matter for advanced customization and scripting.

• On Windows: Use Git Bash (it provides bash). All course examples work here.
• On macOS: Use zsh (the default). All course examples work here too, because zsh understands bash commands.
• On Linux: Use bash (the default). This is what most tutorials assume.

The bottom line: do not spend time choosing a shell right now. When you see command examples in this course, they will work in bash, zsh, and Git Bash. If a command is PowerShell-specific, it will be clearly marked.

6. Your First Commands: Navigating the File System

6.1 The Prompt: What It Means and Where to Type

When you open a terminal, you see something like this:

user@computer:~/Documents$

This is the prompt. It tells you:

• Who you are: user (your username)
• Where you are: ~/Documents (your current folder – ~ means your home folder)
• The shell is ready: $ (this is where you start typing)

On Windows PowerShell, the prompt looks different but conveys the same information:

PS C:\Users\you\Documents>

You type your command after the prompt symbol ($ or >) and press Enter to execute it.

Important: When you see commands in tutorials or documentation, the $ at the beginning is the prompt – do not type it. If the tutorial shows:

$ git status

You only type git status and press Enter.

6.2 Essential Navigation Commands

These are the commands you will use most often. Learn these and you can navigate any system.

Notice that many commands are the same in bash and PowerShell. PowerShell defines aliases (shortcuts) like ls, cd, cat, cp, mv, and rm that map to its own commands. This means the basic commands work everywhere.

6.3 Understanding File Paths

A file path is the address of a file or folder on your computer. There are two types:

Absolute path – the full address from the root of the file system:

# Linux/macOS
/home/user/Documents/project/README.md

# Windows
C:\Users\user\Documents\project\README.md

Relative path – an address relative to your current location:

# If you are in /home/user/Documents/
project/README.md         # go into project, then README.md
./project/README.md       # same thing (. means "current directory")
../Downloads/file.zip     # go up one level, then into Downloads

Special path symbols:

Note on path separators: Linux and macOS use forward slashes (/), Windows traditionally uses backslashes (\). Git Bash on Windows accepts both. When in doubt, use forward slashes – they work almost everywhere.

Try this now:

Open a terminal and follow along:

pwd                          # Where am I?
ls                           # What's in this folder?
mkdir terminal-practice      # Create a new folder
cd terminal-practice         # Go into it
pwd                          # Confirm you're inside
touch hello.txt              # Create an empty file
ls                           # Verify the file was created
echo "Hello Terminal" > hello.txt   # Write text into the file
cat hello.txt                # Read the file contents
cd ..                        # Go back up one level
ls                           # Verify terminal-practice exists

7. Using Programs in the Terminal: The Example of Git

7.1 What Happens When You Type a Command

Every terminal command follows a consistent structure. Let us break down a real command you will use in Lecture 1:

git commit -m "Add README file"
 │    │     │  └─────────────── argument: the value for the -m flag
 │    │     └────────────────── flag: short option that modifies behavior
 │    └──────────────────────── subcommand: the specific action to perform
 └───────────────────────────── program: the tool you are running

Program (git) – The software you want to use. The shell looks up this program in your PATH (more on this later).

Subcommand (commit) – What you want the program to do. Git has many subcommands: clone, add, commit, push, pull, status, log, and dozens more.

Flag (-m) – An option that modifies the command’s behavior. The -m flag tells commit that the next thing you type is the commit message. Without -m, git would open a text editor for you to write the message.

Argument ("Add README file") – The data or value you provide. Here, it is the actual commit message text. The quotes are needed because the message contains spaces.

Not every command has all four parts. Some are simple:

git status        # program + subcommand (no flags or arguments)
ls                # just a program (no subcommand, no flags)
ls -la            # program + flags (-l for long format, -a for all files)
cd Documents      # program + argument (the folder to move into)

7.2 Reading Help Output: Understanding –help

Every well-designed command-line tool includes built-in documentation. The --help flag is your first resource when you do not know how a command works.

$ git --help

This shows a list of all git subcommands with brief descriptions. To get help on a specific subcommand:

$ git commit --help

This opens detailed documentation. The most important part is the synopsis at the top:

SYNOPSIS
       git commit [-a | --all] [-m <msg>] [--amend] [<pathspec>...]

Here is how to read this notation:

So git commit [-m <msg>] means: run git commit, and optionally provide a message with -m followed by your message text.

7.3 Common Patterns Across CLI Tools

Once you understand how one CLI tool works, you can use any of them. These patterns repeat everywhere:

Getting help:

git --help            # help for the program
git commit --help     # help for a specific subcommand
uv --help             # same pattern, different program
ruff --help           # same pattern, different program

Checking the version:

git --version         # or git -v
python --version      # or python -V
uv --version

Short flags vs. long flags – Most flags have two forms:

git commit -m "message"        # short form: -m
git commit --message "message" # long form: --message
# Both do exactly the same thing

Short flags use a single dash and one letter (-m). Long flags use double dashes and a word (--message). Short flags are faster to type; long flags are easier to read.

Combining short flags:

ls -l -a          # two separate flags
ls -la            # combined -- same result, less typing

Try this now:

1. Run git --version – confirm Git is installed
2. Run git --help – scan the list of subcommands
3. Run git commit --help – find the description of the -m flag
4. If you have uv installed, run uv --help – notice the same patterns

8. PATH and Environment Variables

8.1 The Problem: “Command Not Found”

At some point, you will type a command and see something like this:

$ ruff check
bash: ruff: command not found

Or on PowerShell:

PS> ruff check
ruff: The term 'ruff' is not recognized as the name of a cmdlet, function,
script file, or operable program.

This does not mean the program is broken. It usually means the shell does not know where to find the program. This is where PATH comes in.

8.2 What Is the PATH?

When you type a command like git, the shell does not magically know where the git program lives on your hard drive. It needs to search for it.

The PATH is an environment variable that contains a list of folders. When you type a command, the shell searches through these folders in order until it finds a program with that name.

Think of it like a phone book: the shell looks up the name you typed in a list of known addresses.

8.3 How PATH Works on Different Operating Systems

On Linux, macOS, and Git Bash, PATH entries are separated by colons:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/home/user/.local/bin

This means the shell will search these folders in order:

1. /usr/local/bin
2. /usr/bin
3. /bin
4. /home/user/.local/bin

On Windows PowerShell, PATH entries are separated by semicolons:

PS> echo $env:PATH
C:\Windows\System32;C:\Program Files\Git\bin;C:\Users\you\.local\bin

Here is what happens when you type git:

8.4 Other Important Environment Variables

PATH is the most important environment variable, but there are others:

• HOME – your home directory (/home/user on Linux, /Users/user on macOS, C:\Users\user on Windows)
• USER – your username
• LANG – your language setting (affects how programs display text)
• EDITOR – your preferred text editor (used by git when writing commit messages)

You can see the value of any environment variable:

# bash / zsh / Git Bash
echo $HOME
echo $USER

# PowerShell
echo $env:USERPROFILE
echo $env:USERNAME

Environment variables are like global settings for your terminal session. Programs read them to configure their behavior.

8.5 Fixing “Command Not Found” Problems

When you get a “command not found” error, work through this checklist:

Step 1: Is the program installed?

Try installing it. For example, if git is not found, follow the Git installation instructions in Lecture 1.

Step 2: Is the program’s folder in PATH?

Find where the program was installed, then check if that folder is in your PATH:

# bash / Git Bash: find where a program lives
which git
# Output: /usr/bin/git

# PowerShell: find where a program lives
where.exe git
# Output: C:\Program Files\Git\cmd\git.exe

# Alternative PowerShell-native command:
Get-Command git

Why where.exe and not just where? PowerShell has a built-in alias where that maps to Where-Object (a filtering cmdlet) – not the same thing. Using where.exe explicitly calls the Windows system utility that locates executables in PATH. Alternatively, Get-Command is the PowerShell-native way to find where a program lives.

If which, where.exe, or Get-Command also says “not found,” the folder is not in your PATH.

Step 3: Did you restart the terminal after installation?

Many installers add their folder to PATH, but the change only takes effect in new terminal windows. Close your terminal and open a new one, then try again.

Step 4 (advanced): Add the folder to PATH manually.

This varies by system and is usually not needed for this course. If you encounter this situation, ask for help.

Try this now:

1. Run echo $PATH (or echo $env:PATH on PowerShell) – see all the directories your shell searches
2. Run which git (or where.exe git / Get-Command git on PowerShell) – find exactly where git lives
3. Count how many directories are in your PATH (hint: count the separators)

9. What Is a Program? Executables Across Operating Systems

9.1 Programs Are Just Files

A program is a file on your hard drive that contains instructions your computer can execute. That is all it is. There is no magic.

When you “install” a program, you are copying files to your hard drive and (usually) adding the program’s location to your PATH so the shell can find it. When you “run” a program, the operating system reads the file and follows the instructions inside.

9.2 Why .exe on Windows but Not on Linux?

Windows and Linux have different philosophies about how to identify executable files:

This is why, on Windows, you see git.exe in the file system, but on Linux you just see git. Both are the same program doing the same thing – the operating system just identifies them differently.

9.3 Interpreted vs. Compiled (The 30-Second Version)

There are two kinds of programs:

Compiled programs (like git, or a C program):

• The source code is translated into machine code once by a compiler
• The result is a standalone executable file (.exe on Windows, no extension on Linux)
• The computer runs it directly – no extra software needed

Interpreted programs (like Python scripts):

• The source code is read and executed line by line by another program called an interpreter
• The source file (.py) is not an executable on its own
• You need the interpreter installed: python my_script.py means “tell the Python interpreter to read and run this file”

This is why installing Python is necessary before you can run .py files. Python is the interpreter that reads your scripts.

You do not need to understand the details of compilation vs. interpretation for this course. Just know:

• git runs directly (compiled)
• python script.py needs Python installed (interpreted)
• Both are valid ways to create programs

9.4 Programs vs. IDE Extensions: Why Do I Need Both?

When setting up your development environment, you might notice something confusing: you install Python (the program) on your computer, and then you also install the Python extension in VS Code. Same name, but they are two completely different things. Why?

The program (e.g., python, ruff, git) is the actual tool that does the work. It runs in the terminal. When you type python script.py, the Python program reads and executes your code. When you type ruff check, the Ruff program analyzes your code for style issues. These programs exist independently of any editor – they would work the same if you used Notepad, Vim, or no editor at all.

The IDE extension (e.g., “Python” extension, “Ruff” extension in VS Code) is a bridge between VS Code and the program. The extension does not contain a Python interpreter or a linter. Instead, it knows how to talk to the installed program and display the results inside VS Code.

The pattern is always the same:

1. You install the program on your computer (it works in the terminal)
2. You install the extension in VS Code (it makes the program’s output visible in the editor)
3. The extension calls the program – it does not replace it

This is why, if you install the Python extension but forget to install Python itself, VS Code will show an error saying it cannot find a Python interpreter. The extension is looking for the program, and the program is not there.

Think of it this way: The program is the engine. The extension is the dashboard. The dashboard shows you gauges and warning lights, but the engine does the actual work. You need both, but they are not the same thing.

10. Why Automation and Scripting Still Matter

10.1 From Single Commands to Scripts

So far, you have been typing one command at a time. But what if you need to run the same sequence of commands repeatedly?

The progression from manual to automated work looks like this:

1. Single command: mkdir project
2. Chained commands: mkdir project && cd project && git init (runs all three in sequence; && means “and if that succeeded, also do…”)
3. Shell script: Save commands in a .sh file and run them all at once
4. CI/CD pipeline: Commands run automatically when you push code to GitHub

Each level builds on the previous one. Scripting is the bridge between typing commands by hand and fully automated workflows like GitHub Actions (which you will see in Lecture 3).

10.2 A Real Example: Setting Up a Project

Here is what it looks like to set up a new project manually (the steps from Lecture 1):

# Step 1: Create project folder
mkdir my-project

# Step 2: Move into it
cd my-project

# Step 3: Initialize a git repository
git init

# Step 4: Create a README file
touch README.md

# Step 5: Add some content
echo "# My Project" > README.md

# Step 6: Stage all files
git add .

# Step 7: Create the first commit
git commit -m "Initial commit"

Seven commands, typed one by one. Now here is the same thing as a script. Create a file called setup.sh:

#!/bin/bash
# setup.sh -- Create and initialize a new project

PROJECT_NAME="my-project"

mkdir "$PROJECT_NAME"
cd "$PROJECT_NAME"
git init
echo "# $PROJECT_NAME" > README.md
git add .
git commit -m "Initial commit"
echo "Project $PROJECT_NAME created successfully!"

Now you can set up a project with a single command:

bash setup.sh

The script does exactly what you did manually, but faster, without typos, and repeatably. If you need to create 10 projects, you run the script 10 times. If you need to change the setup process, you edit one file instead of remembering a sequence of commands.

10.3 Automation in This Course

Scripting and automation are not just nice-to-have skills – they are central to modern software engineering. In this course, you will encounter:

• Pre-commit hooks: Scripts that automatically check your code before every commit
• GitHub Actions: Automated pipelines that test, lint, and deploy your code when you push
• Pytest: A test runner that automatically finds and runs all your tests
• Ruff: A linter that automatically checks your code style

All of these are built on the same principle: take manual steps and automate them. The terminal is where this automation lives.

Try this now:

1. Create a file called setup.sh with the script above (use any text editor or VS Code)
2. Open a terminal and navigate to where you saved the file
3. Run it: bash setup.sh
4. Check that the folder, file, and git repo were created: ls my-project and cd my-project && git log

11. Quick Reference: Command Cheat Sheet

Keep this table handy as you work through the course. These are the commands you will use most often.

Keyboard shortcuts that work in most terminals:

• Up/Down arrows: Scroll through previous commands (command history)
• Tab: Auto-complete file names and commands (press Tab twice to see all options)
• Ctrl+C: Cancel the current command (useful when something is stuck)
• Ctrl+L: Clear the screen (same as typing clear)
• Ctrl+R: Search your command history (start typing to filter)

12. Summary and Next Steps

You now have the foundation to work confidently in the terminal. Here is what you learned:

• A terminal is a text-based interface for talking to your computer
• A shell (bash, zsh, PowerShell) is the language interpreter running inside the terminal
• Different operating systems have different default terminals and shells, but the core concepts are the same
• Commands follow a consistent pattern: program subcommand --flag argument
• The PATH tells the shell where to find programs
• Programs are just files – the .exe convention is a Windows-specific detail
• Automation through scripting is a core professional skill

Where to go next:

• Ready to install tools? Go to Lecture 1: Installing Git and Installing Python
• Want to set up VS Code? See Lecture 1: Installing and Configuring VS Code
• Ready for Git workflows? See Appendix 1: Advanced Git Workflows
• Want to understand the big picture? Read the Introduction to Modern Software Engineering