Live data from Hacker News

Bash Debugging

wizardzines.com

61–70 of 78 posts

Re: Bash Debugging

#61
post #37

The `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.

I use `set -e` but it has its own quirks. A couple:

An arithmetic expression that evaluates to zero will cause the script to exit. e.g this will exit:

  set -e
  i=0
  (( i++ )) # exits
Calling a function from a conditional prevents `set -e` from exiting. The following prints "hello\nworld\n":

  set -e
  main() {
     false  # does not return nor exit
     echo hello
  }
  if main; then echo world; fi
Practically speaking this means you need to explicitly check the return value of every command you run that you care about and guard against `set -e` in places you don't want the script to exit. So the value of `set -e` is limited.

More at https://mywiki.wooledge.org/BashFAQ/105

Re: Bash Debugging

#62

Earlier quoted context omitted.

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.

> 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.

Over a decade into my career, and I've successfully managed to avoid debugging Bash scripts.

There is hope for people who don't want to.

Re: Bash Debugging

#63
post #49

Earlier quoted context omitted.

You missed the most important tip - use ShellCheck on every script you write: https://www.shellcheck.net/ Personally, I'm a big fan of BASH3 boilerplate: https://github.com/kvz/bash3boilerplate It's fine for BASH versions above v3 and provides decent logging though I typically extend the script so that I can pipe long running commands into its logging framework. It also ensures that you specify the "help" options cor…

Oh yeah, shellcheck is a must have tool.

I think of it as a gateway to writing better scripts. When you first run it and it highlights what it considers to be a problem, you end up reading why it considers it to be a problem and that clues you in on some of the many footguns that Bash has.

Re: Bash Debugging

#64
post #58

Earlier quoted context omitted.

That's a nice list; I guess every experienced user has their helper functions. However, I have a small criticism for the philosophy of that `die`: `die` functions should pass by default the exit code of the failed command, and not silence its error output. If I want to give my own meaning to the command failure in a large script for instance, I will use a different, more specialized `die`. My own die is roughly as fo…

Thanks! Your way is better than what I have. Want to do a pull request? Or may I copy/paste your code?

Just copy paste!

Re: Bash Debugging

#65
Gentoo has a script that you can source at /lib/gentoo/functions.sh that provide various helper methods, mostly for printing messages, and it provides nice little green and red starts to indicate whether something has succeeded of failed.

I use functions.sh in all of my scripts that are known to be running on Gentoo only and it makes them feel Gentoo-y and is useful in general.

Re: Bash Debugging

#66
Off-topic: The alt text for the image says

> Image of a comic. To read the full HTML alt text, click "read the transcript".

but I can't find any button relating to a transcript.

Re: Bash Debugging

#67
I recommend shellcheck as well. It might not catch your problem, but it will point out possible problems.

Also I recommend: rewriting scripts in another language. At work we are converting bash scripts to rust and while it’s a high ramp-up time, the resulting code is much easier to maintain and I have a much higher level of confidence in them. Bash is still good for quick scripts but once you hit 100 lines or so you really deserve a language with stronger guarantees.

Re: Bash Debugging

#68

I recommend shellcheck as well. It might not catch your problem, but it will point out possible problems. Also I recommend: rewriting scripts in another language. At work we are converting bash scripts to rust and while it’s a high ramp-up time, the resulting code is much easier to maintain and I have a much higher level of confidence in them. Bash is still good for quick scripts but once you hit 100 lines or so you…

I agree, but we gotta tell that to CI/CD engineering and yaml-pipelines

Re: Bash Debugging

#69

I recommend shellcheck as well. It might not catch your problem, but it will point out possible problems. Also I recommend: rewriting scripts in another language. At work we are converting bash scripts to rust and while it’s a high ramp-up time, the resulting code is much easier to maintain and I have a much higher level of confidence in them. Bash is still good for quick scripts but once you hit 100 lines or so you…

I agree, but we gotta tell that to CI/CD engineering and yaml-pipelines

When I was at Facebook, I wrote a Python script to extract shell scripts from GitHub Actions workflows, so we could run them all through ShellCheck: https://github.com/pytorch/pytorch/blob/69e0bda9996865e319db...
Post reply on HN