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

41–50 of 78 posts

Re: Bash Debugging

#41

Post by wolletd »

porlw wrote: post #39
wolletd wrote: post #37

Earlier quoted context omitted.

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.

Well, otherwise `if grep "line" $file; then` wouldn't work, which in my opinion is the primary use case for grep in scripts.

I'd still prefer a `grep || true` over not having `set -e` for the whole file.

Re: Bash Debugging

#42

Post by gpvos »

ykonstant wrote: post #26
whatindaheck wrote: post #22

Earlier quoted context omitted.

Could killing the PID like that create zombies?

Perhaps, but in any case I would never write code like this. First of all, sending sigkill is literally overkill and perpetuates a bad practice. Send `TERM`. If it doesn't work, figure out why. Secondly, subshells should be made as clear as possible and not hidden in pipes. Related, looping over `read` is essentially never the right thing to do. If you really need to do that, don't use pipes; use heredocs or herestri…

> looping over `read` is essentially never the right thing to do

Why? I do it quite often, though admittedly usually in one-time scripts.

Re: Bash Debugging

#43

Post by xk_id »

HankB99 wrote: post #24
awesomeMilou wrote: post #11

Earlier quoted context omitted.

Are you sure it's bash? Most scripts on FreeBSD's are written for sh, which I feel is much more widely supported due to being part of the POSIX standard. Bash is just popular I think.

Bash is pretty much expected to be installed on any Linux distro. On FreeBSD (and likely other BSDs) it is an optional install. If you want a script to run on either, use sh. If strictly Linux, bash is probably safe. Bash/sh is good for when you need to combine some commands and what needs to be done can be accomplished mostly by CLI commands with a little glue to tie them together. Some times it is surprising what c…

> Bash/sh is good for when you need to combine some commands and what needs to be done can be accomplished mostly by CLI commands with a little glue to tie them together.

Once I’ve learned bash, I realised how much more problems i could solve, in addition to a majority of old ones. It’s an entirely new level of “computer literacy”; and a more genuine one.

Re: Bash Debugging

#44

Post by ndsipa_pomu »

asicsp wrote: post #9

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-b…

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 correctly as it parses the usage information to process the command line arguments with support for short and long options.

Re: Bash Debugging

#45

Post by qazxcvbnm »

ykonstant wrote: post #26
whatindaheck wrote: post #22

Earlier quoted context omitted.

Could killing the PID like that create zombies?

Perhaps, but in any case I would never write code like this. First of all, sending sigkill is literally overkill and perpetuates a bad practice. Send `TERM`. If it doesn't work, figure out why. Secondly, subshells should be made as clear as possible and not hidden in pipes. Related, looping over `read` is essentially never the right thing to do. If you really need to do that, don't use pipes; use heredocs or herestri…

Do enlighten me on why it is a bad idea to use loops over read; it's perhaps one of my favourite patterns in bash, and combined with pipes, appears to me one of the cleanest ways to correctly and concisely utilise parallelism in software.

Re: Bash Debugging

#46

Post by ndsipa_pomu »

colordrops wrote: post #10

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?

Its legacy usage is certainly a big part of its popularity. You can generally rely on having a newish version of it on any modern distro and you don't have to worry about the version unless you want to do stuff with arrays etc.

What I find compelling about bash is its position in relation to other languages and tools. It's ideal for tying together other tools and is close enough to the operating system to make that easy whilst also not requiring libraries to also be installed (c.f. python).

I often hear the opinion that more complex scripting should be moved to a language such as python, but that adds a layer of complexity that is probably not helpful in the long-run. I can take a bash script that I wrote twenty years ago and it'll still work fine, but a python programme from twenty years ago may well have issues with versions.

Re: Bash Debugging

#47

Post by ndsipa_pomu »

bigstrat2003 wrote: post #33
sureglymop wrote: post #20

Earlier quoted context omitted.

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.

What language would you base a pipeline on?

I agree that bash sucks, but have yet to find anything to replace it that doesn't increase complexity and version problems.

Re: Bash Debugging

#49

Post by asicsp »

ndsipa_pomu wrote: post #44
asicsp wrote: post #9

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-b…

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.

Re: Bash Debugging

#50

Post by mellutussa »

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

This is a lifesaver. Although I save the -x until I really need to see all the garbage debug output.
Post reply on HN