Bootcamp
A two-week sprint to be production-ready writing bash and shell tools.
Bootcamp plan
EXAMPLE
# Bash bootcamp - 10 working days
Day 1 - Tooling: zsh or bash, choose one; install starship or oh-my-zsh; learn your terminal.
Day 2 - Strict mode: set -Eeuo pipefail, IFS, traps, ERR/EXIT.
Day 3 - Quoting + expansion: single vs double, \${var:-default}, \${var/from/to}.
Day 4 - Pipes + redirection: stdin, stdout, stderr, here-docs, process substitution.
Day 5 - Tools: grep, sed, awk, jq, xargs - drill them on real logs.
Weekend project: write a tiny shell linter for a custom config format.
Day 6 - Functions + libraries: return codes, local variables, structured logs.
Day 7 - getopts + usage: command-line tool that someone else can read.
Day 8 - Testing: bats-core for unit tests, mock external commands.
Day 9 - ShellCheck + CI: enforce in pull requests.
Day 10 - Productionisation: cron + systemd timers, alerting on failure.
Capstone: write a deploy script for a small service that retries safely.
## Tips
- Strict mode is non-optional
- ShellCheck in CI catches what code review misses
- Test with bats-core; mocking commands is half the battle
- Reach for Python instead of bash once a script crosses 200 lines
## Common mistakes
- Forgetting quotes on \$var (most common bug)
- Globbing where you wanted a literal asterisk
- Subshell loss when piping into while read
- Trusting set -e to catch everything (it does not)
Why it matters
Bash is everywhere and never going away. Drill the quoting rules, master strict mode, run ShellCheck on every file. After 200 lines, switch to Python - that is not a failure of bash, just a sensible boundary.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Discussion
Loading…