Build the mental model
A shell script is nothing mysterious — it's a plain text file holding the same commands you already type at the terminal, saved in order so bash can run them one after another instead of you retyping them by hand every time. Formalizing commands into a file instead of just relying on shell history matters because history is unordered, easy to lose, and personal to your machine, while a script is a deliberate artifact anyone can read, review, and re-run identically. The shebang line, `#!/usr/bin/env bash`, is what the kernel inspects first when you execute a file directly: a `#!` on the very first line tells the OS which interpreter should read the rest of the file, and using `env` to look up `bash` on the `PATH` — rather than hardcoding a path like `/bin/bash` — keeps the script portable, since bash doesn't live in the same place on every system. Even with a correct shebang, the kernel still won't run a script directly until you grant it the executable bit with `chmod +x`; after that, `./script.sh` works on its own, and without it you have to invoke `bash script.sh` explicitly, which sidesteps the shebang entirely because you're already naming the interpreter yourself. The real payoff of scripting isn't any single command — it's converting a sequence of steps you'd otherwise retype by hand, and occasionally get wrong under pressure, into something reliable, reviewable, and shareable with a whole team.
Connect it to a real scenario
Imagine you deploy a small app and every release you manually run the same five commands: pull the latest code, install dependencies, run the tests, restart the service, and check the logs. Typing that sequence by hand every time invites mistakes — skipping a step under pressure, mistyping a flag, forgetting which order they run in, or running an old test suite because you copy-pasted from the wrong terminal history entry. Wrapping those five commands into a single `deploy.sh` script means anyone on the team can run one command and get the exact same, correct sequence every time, regardless of who's tired or in a hurry. The lesson's own example works the same way on a smaller scale: instead of manually echoing a status line for Alice, then Bob, then Carol, the script loops over the names once and prints a consistent, formatted report — the kind of small automation that, multiplied across a team's daily habits, is exactly what makes scripting worth learning first.
Try the working example
#!/usr/bin/env bash
# A simple script that automates a repetitive task:
# printing a formatted greeting for multiple users.
echo "Daily Standup Report"
echo "====================="
for user in Alice Bob Carol; do
echo "- $user: all tasks on track"
done
echo "Report generated."Running this script prints:
Daily Standup Report
=====================
- Alice: all tasks on track
- Bob: all tasks on track
- Carol: all tasks on track
Report generated.5-minute try-it
Write a script that prints a short checklist of three tasks you do every morning (for example, checking email, reviewing a calendar, and checking build status), each on its own line, and make the file executable with chmod +x before running it.
One important caution
Forgetting chmod +x and then being confused why './script.sh' returns 'Permission denied'
Leaving out the shebang line (or getting its path wrong), so the script runs with whatever shell happens to invoke it instead of bash
GNU Bash Reference Manual — Bash / Shell Scripting