Advanced Shell Scripting with Bash (2006) [pdf]

Original Article ↗ Hacker News Discussion ↗

Access to the material and updates

  • Original 2006 slides are still available (HTTP and archive); confusion arose from lack of HTTPS.
  • A new 2025 talk, “Seat Belts and Airbags for bash,” with updated slides and an 87‑minute video is linked.
  • The same author maintains a stringent.sh library used in the newer talk, available on GitHub.

Safer Bash scripting practices

  • The slides and newer talk focus on avoiding Bash pitfalls and building “production‑quality” scripts rather than teaching basic syntax.
  • People highlight set -e/errexit, pipefail, and especially trapping ERR with LINENO for stack‑trace‑like debugging.
  • Greg’s Bash wiki and ShellCheck are repeatedly recommended as core resources for learning good patterns and avoiding common mistakes.
  • There is interest in reference variables as a safer alternative to eval, and in potentially expanding material to cover debugging and use with sudo.

Anti‑patterns and the limits of Bash

  • Several commenters argue that “advanced” Bash is usually a bad idea; the main skill is knowing when to stop and switch languages.
  • A notorious pattern buggy_command || : is called out as effectively “a penny in the fusebox,” hiding failures in deployment scripts.
  • Some stress that complex parameter expansion (${var##pattern}, deep nesting) quickly becomes unreadable and unmaintainable.

Alternatives to Bash for scripting

  • Many share “replacement” or “escape hatch” languages: Python, Ruby, Perl, Raku, Lua (and LuaJIT), awk/gawk, Guile, QuickJS‑based JS, zx, xonsh, nushell, Elvish, Murex, Oil, NGS, schemesh.
  • Tradeoffs discussed include startup cost, availability on target systems, standard library richness, subprocess ergonomics, typing, and learning curve.
  • Views differ on stringly‑typed languages (Bash, Tcl, Perl): some see them as inherently fragile; others defend Perl and modern Tcl as more capable than caricature suggests.

What shells are really for

  • Several comments frame Bash primarily as a “subprocess orchestration language” whose superpower is piping and job control, not rich data structures.
  • Guidelines emerge: use Bash for simple glue around existing tools and environment setup; use a general‑purpose language once you need complex flow, data structures, or nontrivial text/structured‑data processing.
  • A linked parable (“Emperor Sh and the Traveller”) and personal practices reinforce the idea that good shell scripts wrap existing tools rather than re‑implement them.