Shell, Shebangs & the First Script

Everyone "knows" bash. Almost nobody knows what it actually does between you pressing Enter and something happening. That gap is where every confusing shell bug lives, so we start by closing it — then we set up the two habits that will keep you out of trouble for the rest of the course.

What bash actually is

Bash is three things wearing one coat, and conflating them is the source of a lot of confusion:

1. An interactive interface — the prompt, history, tab completion, job control.
2. A command interpreter — it finds programs and runs them.
3. A programming language — variables, functions, conditionals, loops.

The third one is the one people skip, and it's why so much shell code in the wild is written by superstition. This course treats bash as a language you learn properly, not a place you paste commands.

What happens when you press Enter

For every line you type, bash runs a fixed pipeline. Knowing the order explains almost every "why did it do that?" moment you will ever have:

1. Split into words on whitespace.
2. Expand — this is a whole sequence in itself: brace expansion, tilde, then parameter/variable expansion, command substitution and arithmetic, then word splitting, then filename globbing.
3. Redirect — set up any >, <, or pipes.
4. Locate the command — a function? a builtin? something on PATH?
5. fork + exec — for an external program, bash clones itself and replaces the clone with the new program.

The shebang

The first line of a script tells the kernel which interpreter to run it with. It only works if it is genuinely the first two bytes of the file — no blank line, no comment, no byte-order mark above it.

#!/usr/bin/env bash   # find bash on PATH — portable, preferred
#!/bin/bash           # a fixed path — fine on Linux, wrong on some BSDs
#!/bin/sh             # POSIX shell — NOT bash. No arrays, no [[ ]].

#!/usr/bin/env bash is the default you should reach for: it finds whichever bash is first on PATH, which on a Mac with Homebrew bash is the modern one rather than Apple's ancient 3.2. The tradeoff is that it obeys PATH, so in a security-sensitive setuid-adjacent context a fixed path is safer — we return to that in Module 17.

Writing #!/bin/sh at the top of a script full of bash features is the single most common portability bug in this whole subject. On Debian and Ubuntu /bin/sh is dash, which has no arrays and no [[ ]]. The script will work on your machine and fail on the target. Module 15 is dedicated to this.

Three ways to run a script — and why they differ

./script.sh      # needs +x and a shebang. Runs in a NEW process.
bash script.sh   # no +x needed, shebang ignored. Also a NEW process.
source script.sh # runs in YOUR CURRENT shell. No new process.
. script.sh      # identical to source — the POSIX spelling

The distinction is not cosmetic. A new process gets a copy of your environment, so anything it changes — variables, the working directory — vanishes when it exits. That is why a script that ends in cd /somewhere appears to "not work": it did work, in a process that no longer exists.

How a command is actually found

When you type a name, bash resolves it in a strict order — and it is not "search PATH":

1. Alias (interactive shells only)
2. Function you have defined
3. Builtin — cd, echo, test live inside bash itself
4. PATH lookup — first match wins, left to right

Use type -a name to see every match in order — it is strictly more informative than which, which only knows about step 4 and is an external program on some systems. For scripts, use command -v name: it is a builtin, it is POSIX, and it is the correct way to ask "does this exist?".

$ type -a echo
echo is a shell builtin
echo is /bin/echo          # two different echoes, subtly different flags!

# The right existence check in a script:
if command -v jq >/dev/null 2>&1; then ...

The safety header

Start every script you write from here on with this. We will unpack each flag properly in Module 04 — including the important caveat that set -e is subtler than it looks — but adopt it now so the habit is automatic:

#!/usr/bin/env bash
set -euo pipefail

# -e  exit on an unhandled command failure
# -u  treat an unset variable as an error (catches typos in variable names)
# -o pipefail  a pipeline fails if ANY stage fails, not just the last one

Without pipefail, grep pattern file | sort reports success even when grep found nothing, because sort succeeded. That default has silently broken a lot of production scripts.

Install shellcheck now, not later

shellcheck is a static analyser for shell. It catches the entire class of quoting bugs Module 01 is about, plus a few hundred others, and it explains each one with a wiki link. Treat a shellcheck warning like a compiler error.

brew install shellcheck      # macOS
sudo apt install shellcheck  # Debian/Ubuntu

shellcheck myscript.sh