<aside> 🐚

Module 1 — The Shell, Scripts, and How Commands Run. Every deploy script, CI step, and cron job is just commands in a file — this module teaches what actually happens when you run one.

🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)

</aside>

<aside> 📋

Before you start. This is the first module — no earlier modules are needed. You need: a computer with a terminal running Linux (any distribution; Ubuntu is what the examples were tested on), or macOS, or Windows with WSL; and the text editor nano, which is preinstalled almost everywhere. Check your setup by opening a terminal and typing bash --version — any version 4 or higher is fine. One caveat this track cannot check for you: macOS ships a very old bash by default. Run bash --version on your Mac; if it says 3.x, most of this track still works, but a few later features will not — installing a newer bash via Homebrew fixes that.

</aside>

Part A — What is actually happening when you type a command?

A1. The terminal, the shell, and the kernel

<aside> 📖

Official docs: bash(1) — Linux manual page

</aside>

When you open a "terminal" and type a command, three separate pieces of software are involved, and people mix them up constantly.

The terminal is just the window — a program that draws text on screen and sends your keystrokes onward. It understands nothing about commands.

The shell is the program running inside that window, reading what you type. On most Linux systems it is bash (the Bourne Again Shell). The shell's job is to take a line of text like ls -l /tmp, figure out what program you want to run and with what inputs, start that program, and show you what came back.

The kernel is the core of the operating system. It is the only thing that can actually start programs, read disks, or talk to the network. The shell never does any real work itself — it asks the kernel to do it.

So bash is not "the terminal" and not "Linux". It is an ordinary program whose specialty is launching other programs. That has a huge consequence: anything you can type at the prompt can be saved in a file and replayed later. A file of shell commands is called a shell script, and a shell script is nothing more exotic than that — typed commands, saved.

One more distinction you will need in a moment: some commands are programs — separate files on disk that the shell finds and asks the kernel to run (ls is one). Others are builtins — abilities wired into bash itself, so no separate program is started (cd is one). You can ask bash which is which with the command type.

<aside> 🧩

Real-world analogy — the restaurant. The terminal is the table and the menu — the furniture where the interaction happens. The shell is the waiter: it takes your order written in human shorthand, translates it into precise kitchen instructions, carries them to the kitchen, and brings the dish back to your table. The kernel is the kitchen: the only place where food is actually cooked. Ordering "the usual" works because the waiter interprets; the kitchen would not know what to do with those words. A shell script is a pre-written order slip you hand over: "bring water, then the soup, then the bill."

Where the analogy stops working. A real waiter passes your order along roughly as you said it. The shell does not — before anything reaches the kernel, bash rewrites your command line: it splits it into words, expands special patterns, and substitutes values. You will meet this rewriting machinery in Module 2, and it is the single most important thing about bash that beginners do not expect.

</aside>

🧪 Exercise 1.1 — meet your shell

bash --version    # which shell, which version?
type cd           # is cd a separate program, or built into bash?
type ls           # and ls?

A2. How the shell finds commands — PATH

<aside> 📖

Official docs: Bash manual — Bourne Shell Variables (documents PATH) · env(1) — Linux manual page

</aside>

When you type ls, bash does not search your whole disk — that would take minutes. Instead it keeps a short list of directories where programs are allowed to live, and checks only those, in order, left to right, stopping at the first match. That list is called PATH.

You can print it with the command printenv PATH (printenv is a small program that prints one of the shell's stored settings — these settings are called environment variables, and Module 2 teaches them properly; for now you only need to look at this one).