Bash scripts are terrible because most of us write them like we’re drunk — ignoring errors, letting variables expand into dangerous whitespace, and building sprawling messes that explode on a filename with a space. The fix is discipline: treat Bash like application code. Use strict mode, quote every variable, and handle errors properly. I learned this debugging a silent Ubuntu 24.04 CI failure last Tuesday that exited with code 0 but never deployed.
It’s 2026. We have Rust CLIs that run at the speed of light. We have AI agents that can generate entire Python microservices while I make coffee. Yet, open any repository—backend, frontend, infrastructure, doesn’t matter—and look at the .github/workflows or the deploy/ folder. What do you see?
Shell scripts. Everywhere.
Bash is the cockroach of the programming world. It survives everything. It survives the “Rewrite it in Go” movement. It survives the “Python is easier” argument. It survives because sometimes you just need to glue three commands together and piping output is faster than importing subprocess in Python.
The problem isn’t Bash itself. The problem is that most of us write Bash like we’re drunk. We ignore errors, we let variables expand into dangerous whitespace, and we create unmaintainable sprawling messes that explode the moment a file name has a space in it.
I spent last Tuesday debugging a silent failure in a CI pipeline running on Ubuntu 24.04. The script exited with code 0 (success), but the deployment didn’t happen. Why? Because a command in the middle of a pipe failed, and Bash, by default, only cares about the exit code of the last command in the pipe.
But for that deployment glue? For that Docker entrypoint? For that quick CI check? Bash is still king. Just treat it with the same discipline you treat your application code. Use strict mode. Quote your variables. And for the love of everything holy, handle your errors.
Common questions
Why does a Bash script exit with code 0 when a command in the middle of a pipe fails?
By default, Bash only reports the exit code of the last command in a pipeline, so failures in earlier piped commands are silently ignored. This caused a silent CI failure on Ubuntu 24.04 where a deployment script exited successfully despite a mid-pipe failure, and the deployment never happened. Enabling strict mode (like pipefail) is the fix to catch these hidden errors.
Why is Bash still used everywhere in 2026 despite Rust and Python alternatives?
Bash survives because it excels at gluing a few commands together and piping output, which is faster than importing Python’s subprocess module. Open any repository’s .github/workflows or deploy/ folder and you’ll find shell scripts everywhere. It has outlasted the ‘Rewrite it in Go’ movement and the ‘Python is easier’ argument, remaining king for deployment glue, Docker entrypoints, and quick CI checks.
Why do Bash scripts break when file names contain spaces?
Bash scripts break on spaces because developers fail to quote their variables, allowing variable expansion to split on whitespace and produce dangerous, unintended behavior. The article argues the problem isn’t Bash itself but that most people write it carelessly—ignoring errors and letting variables expand unsafely. Quoting your variables is a core discipline that prevents scripts from exploding the moment a filename contains a space.
How do you make Bash scripts more reliable and maintainable?
Treat Bash with the same discipline you treat application code. Use strict mode so failures aren’t silently swallowed, quote every variable to prevent whitespace-related explosions, and handle your errors explicitly rather than ignoring them. The article stresses that Bash itself isn’t the problem—unmaintainable sprawling messes come from writing it ‘like we’re drunk,’ not from any fundamental flaw in the language.
