The `trap DEBUG` thing is pretty interesting; I almost always write POSIX code, so I don't get to play with such tricks. Does anybody know of some wizardry that could mimic this in arbitrary POSIX compliant shells?
Bash Debugging
31–40 of 78 posts
Re: Bash Debugging
#32Is there a reason bash is still the de facto shell scripting language other than sheer momentum of legacy? I'm able to get what I need done in it, but it's clunky and the syntax is horrid. I guess it forces you to move to a proper language once scripts grow to a certain size/complexity, so perhaps it's by design?
It's ubiquitous.
But bash is so bad I wrote a ton of namespace shortened utils for using groovy scripts.
Sooooooooooooooooo much better. use IDEs for dev, save library system, groovy smoothed almost all Java annoyances
Re: Bash Debugging
#33If I ever have to debug anything in bash. I stop using bash hah.
Doesn't make sense. What if you get a script someone else wrote? Printing every command and confirming as you run every command is a great idea. And, unfortunately shell has become the norm in CI/CD environments, pipelines etc. Can be convenient at times but can also be inconvenient and confusing as these scripts don't run in interactive shells.
> And, unfortunately shell has become the norm in CI/CD environments, pipelines etc.
A pipeline which relies on shell is not worth using, tbh. That's how much shell sucks.
Re: Bash Debugging
#34If I ever have to debug anything in bash. I stop using bash hah.
I find such reasoning backwards. Indeed, shell scripting is not friendly to debugging. But ensuring correctness of shell scripts is essential: usually, they touch part of your "$HOME" or system folders and do tons of I/O, some of it destructive. I find it baffling to see people write careless scripts; sometimes using `rm` for cleanup with unquoted parameters, or much worse, dangerous uses of `mv`.
I believe OP's point was that any shell script complex enough to require debugging should not be a shell script any more.
Re: Bash Debugging
#35This is neat, never considered one could step debug a bash script. Kudos for sharing!
Re: Bash Debugging
#36Earlier quoted context omitted.
I find such reasoning backwards. Indeed, shell scripting is not friendly to debugging. But ensuring correctness of shell scripts is essential: usually, they touch part of your "$HOME" or system folders and do tons of I/O, some of it destructive. I find it baffling to see people write careless scripts; sometimes using `rm` for cleanup with unquoted parameters, or much worse, dangerous uses of `mv`.
I believe OP's point was that any shell script complex enough to require debugging should not be a shell script any more.
While that's certainly true for people trying to do very complex things in "pure" shell, when the tools you're using are possibly buggy, it's not very useful. Sometimes you have to debug and figure out where the problem is occurring, an then you can do the much simpler work of replacing one part rather than writing a bespoke program to replace all the boring functionality obfuscated away by shell and the working programs.
Re: Bash Debugging
#37The `die()` trick is good, but bash has an annoying quirk: if you try to `exit` while you're inside a subshell, then the subshell exits but the rest of the script continues. Example: #!/bin/bash die() { echo "$1" >&2; exit 1; } cat myfile | while read line; do if [[ "$line" =~ "information" ]]; then die "Found match" fi done echo "I don't want this line" ..."I don't want this line" will be printed. You can often avoi…
Just adding `set -e` also exits the script when a subshell exits with non-zero error code. I'm not sure why I would leave `set -e` out in any shell script.
Re: Bash Debugging
#38I shared https://johannes.truschnigg.info/writing/2021-12_colodebug/ a while ago here - you might appreciate it for another means to make your bash scripts easier to understand while they execute.
Re: Bash Debugging
#39The `die()` trick is good, but bash has an annoying quirk: if you try to `exit` while you're inside a subshell, then the subshell exits but the rest of the script continues. Example: #!/bin/bash die() { echo "$1" >&2; exit 1; } cat myfile | while read line; do if [[ "$line" =~ "information" ]]; then die "Found match" fi done echo "I don't want this line" ..."I don't want this line" will be printed. You can often avoi…
Just adding `set -e` also exits the script when a subshell exits with non-zero error code. I'm not sure why I would leave `set -e` out in any shell script.
grep has a bad interaction with set -e, since it (infuriatingly) exits with 1 if no lines are matched.
Re: Bash Debugging
#40Earlier quoted context omitted.
I find such reasoning backwards. Indeed, shell scripting is not friendly to debugging. But ensuring correctness of shell scripts is essential: usually, they touch part of your "$HOME" or system folders and do tons of I/O, some of it destructive. I find it baffling to see people write careless scripts; sometimes using `rm` for cleanup with unquoted parameters, or much worse, dangerous uses of `mv`.
I believe OP's point was that any shell script complex enough to require debugging should not be a shell script any more.
I believe P's point was that it doesn't matter how simple or complex a script (or anything else) is, everything requires debugging. And/or that you have to be ready to debug bash regardless if you like it or not, regardless what you choose to write your own stuff in.
OP's comment is not unfunny and not 100% untrue either though. But not 100% true either. A single word script still needs to be debugged.