Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bash Debugging

wizardzines.com

Post reply on HN
Print view View original

1–10 of 78 posts

Re: Bash Debugging

#2

Post by memco »

Good stuff! I use set-x frequently and have used a similar thing to die (but Julia’s version is nicer). I’ll consider using the debugger thing but stepping through a bash script line by line sounds a bit tedious. Perhaps less so than having to reread a log and rerun the script a bunch.

Re: Bash Debugging

#3

Post by chatmasta »

memco wrote: post #2

Good stuff! I use set-x frequently and have used a similar thing to die (but Julia’s version is nicer). I’ll consider using the debugger thing but stepping through a bash script line by line sounds a bit tedious. Perhaps less so than having to reread a log and rerun the script a bunch.

The line-by-line debugging would probably only be useful for a particular section of your script that you're trying to fix. In that case, you can remove the trap at the end of it with `trap - DEBUG`

Re: Bash Debugging

#4

Post by klysm »

I always put

set -euxo pipefail

at the top of my bash scripts. It makes some conditional testing more difficult but it has paid for itself many times over just because of pipefail

Re: Bash Debugging

#5

Post by ddlsmurf »

klysm wrote: post #4

I always put set -euxo pipefail at the top of my bash scripts. It makes some conditional testing more difficult but it has paid for itself many times over just because of pipefail

You can also set it for a bunch of lines then deactivate it with `set +x`. It gets rather tedious otherwise...

Re: Bash Debugging

#6

Post by Brian_K_White »

I have almost that same die() in every script, except I call it abrt(). Maybe I'll switch to die() since it's shorter. Mine also prepends $0 and sometimes I use printf or echo -e so I can pass larger more complex messages with linefeeds and escape codes etc.

Re: Bash Debugging

#7

Post by halostatue »

memco wrote: post #2

Good stuff! I use set-x frequently and have used a similar thing to die (but Julia’s version is nicer). I’ll consider using the debugger thing but stepping through a bash script line by line sounds a bit tedious. Perhaps less so than having to reread a log and rerun the script a bunch.

I often add a fail-unless function:

    fail-unless() {
      local result
      "$@"
      result=$?

      if ((result != 0)); then
        echo >2&1 "Failed  ${result} with command '$*'."
        exit ${result}
      fi
    }
That way, I know exactly what failed in the script.

Re: Bash Debugging

#9

Post by asicsp »

See also:

Why doesn't set -e (or set -o errexit, or trap ERR) do what I expected? https://mywiki.wooledge.org/BashFAQ/105

What are the advantages and disadvantages of using set -u (or set -o nounset)? https://mywiki.wooledge.org/BashFAQ/112

Safe ways to do things in bash https://github.com/anordal/shellharden/blob/master/how_to_do...

Better Bash Scripting in 15 Minutes https://robertmuth.blogspot.com/2012/08/better-bash-scriptin...

Writing Robust Bash Shell Scripts https://www.davidpashley.com/articles/writing-robust-shell-s...

Re: Bash Debugging

#10

Post by colordrops »

Is 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?
Post reply on HN