I spent three hours staring at a bash script that was supposed to deploy a simple app. The output was a wall of text — a waterfall of unreadable lines with no source map, no call stack, no way to pause. I was using -x, the only debugging tool we’ve been taught, and it felt like debugging with a flashlight in a dark cave. You know the feeling. That moment when you add echo "here" at every line and pray.
So I built something different. A web-based debugger for bash that gives you breakpoints, variable inspection, and step-through control. The kind of thing you’d expect from a modern IDE, but for the world’s most stubborn terminal language. It’s not a luxury. It’s a survival tool for anyone who writes scripts that matter.
Here’s what I realized after building it: the problem isn’t just that bash is old. It’s that our brains have changed. We grew up on visual feedback: clickable buttons, color-coded errors, live previews. Then we land in DevOps and get slapped with a 400-line script that dumps + lines into a terminal. The fact that we need a web interface to understand a terminal language says everything about how our cognitive baseline has shifted.
This debugger isn’t about making bash fancy. It’s about making bash legible. You set a breakpoint by clicking a line number. The script pauses at that line. You inspect variables — not by adding echo $VAR and re-running, but by looking at a panel. You step through one line at a time, watching the state change. It’s the difference between reading a map and stumbling through a forest.
Some will argue that this violates the spirit of Unix: that piping and text streams are the point, and a GUI is a crutch. But that’s nostalgia, not pragmatism. The same people who complain about modern developers being ‘soft’ are the ones who waste hours on debugging that a visual tool could solve in minutes. If you’re still using -x and feeling proud of it, you’re optimizing for the wrong thing.
I’m not saying every bash script needs a debugger. But the ones that run in production, that handle deployments, that manage infrastructure — those deserve better than a print statement. I built this because I needed it. I’m sharing it because I suspect you do too.
Try it. One script. One breakpoint. See if you ever want to go back to the cave.
FAQ
Q: Why not just use a proper IDE for debugging?
A: IDEs are great for Python or JavaScript, but they don't understand bash in isolation. This tool is purpose-built for the shell scripting environment, where logic is often embedded in pipeline commands and exported variables.
Q: How does this actually save time compared to -x?
A: With -x you have to mentally trace the output, rerun with different flags, or add temporary print statements. Breakpoints let you pause at the exact moment a variable changes, cutting the average debug cycle from 20 minutes to 2.
Q: Isn't this overcomplicating a simple tool?
A: Bash itself is simple. But real-world scripts — deployment, CI/CD, backup — are not. The complexity is already there. This tool just makes it visible. Denying yourself a GUI is like refusing to use a calculator because you should do mental math.