Behind every command-line prompt sits a shell — a program whose job is to read what you type, expand it according to a long list of rules, and ask the operating system to run the result. Almost every server, container, and CI runner you will ever touch is administered through one.
Shells You Will Meet
| Shell | Where | Notes |
|---|---|---|
| sh (POSIX) | Minimal containers, /bin/sh | Smallest common subset; portable scripts target this |
| Bash | Most Linux servers, WSL, default on older macOS | The standard for serious shell scripting |
| Zsh | Default on modern macOS | Bash-compatible enough for most scripts; better interactive UX |
| Dash | /bin/sh on Debian/Ubuntu | Fast and POSIX-strict; surprises Bash-trained scripts |
| Fish | Opt-in | Friendly; not Bash-compatible |
| PowerShell | Windows, cross-platform | Different paradigm — objects, not text |
This course teaches Bash. The patterns transfer to Zsh almost entirely and to sh with care.
What a Shell Actually Does
When you type:
ls -la /var/log | grep error
Bash performs roughly these steps:
- Tokenises the line (words, operators, quoting).
- Expands aliases.
- Expands variables, command substitutions, arithmetic, brace expansion.
- Globs filenames (e.g.
*.txt). - Splits redirections from commands.
- Forks processes for each pipeline stage and connects their stdin/stdout via pipes.
- Waits for them to finish; reports the exit code.
Most shell bugs come from misunderstanding step 3 or step 4 — quoting and word splitting. We will cover those in detail.
Interactive vs Non-Interactive
- Interactive — you type at a prompt; the shell prints results and waits.
- Non-interactive — a script runs from top to bottom; no prompt; intended for automation.
The same Bash binary handles both. A few features (history, line editing, prompts) only apply interactively. A few rules (errors stopping execution, set -e behaviour) become more important in scripts.
Why Bash Still Matters
Despite Python, Go, and a thousand more elegant alternatives, shell scripts persist because:
- They are everywhere — every Linux box, every container, every CI image.
- They glue together programs cheaply — no language can pipe processes more concisely.
- The startup cost is zero — no virtual env, no compile step.
- They are how Linux itself is configured (systemd unit ExecStart, init scripts, package post-installs).
The price you pay is care: shell is a small language with a lot of footguns. The remaining lessons teach you to avoid them.
Your First Look at the Shell
$ echo "Hello, $USER"
Hello, alice
$ pwd
/home/alice
$ ls
docs notes.txt project
$ is the prompt; echo, pwd, ls are commands. $USER is a variable. That handful of concepts is the foundation everything else builds on.
What's a Script?
A shell script is a text file with a shebang line and shell commands. Mark it executable, and it runs.
#!/usr/bin/env bash
echo "Backup starting at $(date)"
tar -czf /tmp/backup.tgz /etc
chmod +x backup.sh
./backup.sh
That is most of what shell scripting looks like. The lessons that follow add the discipline to make it reliable.
Cert Mapping
| Cert | Shell scope |
|---|---|
| RHCSA / LFCS | System administration entirely from the shell |
| AWS SAA | EC2 user data, Systems Manager run commands |
| KCNA | Container entrypoints, debug shells |
| Terraform Associate | Provisioner scripts, CLI workflows |
The next lesson covers the everyday commands that turn a shell from a typing exercise into a productivity tool.