1529
Like programming in bash (lemmy.ml)
submitted 1 day ago by cm0002@lemmy.world to c/programmer_humor@programming.dev
177 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[-] 0x0@lemmy.dbzer0.com 56 points 1 day ago

PSA: Run ShellCheck on your shell scripts. It turns up a shocking number of programming errors. https://www.shellcheck.net/

[-] HyperMegaNet@lemm.ee 7 points 23 hours ago

Thank you for this. About a year ago I came across ShellCheck thanks to a comment just like this on Reddit. I also happened to be getting towards the end of a project which included hundreds of lines of shell scripts across dozens of files.

It turns out that despite my workplace having done quite a bit of shell scripting for previous projects, no one had heard about Shell Check. We had been using similar analysis tools for other languages but nothing for shell scripts. As you say, it turned up a huge number of errors, including some pretty spicy ones when we first started using it. It was genuinely surprising to see how many unique and terrible ways the scripts could have failed.

[-] ethancedwards8@programming.dev 5 points 1 day ago

I wish it had a more comprehensive auto correct feature. I maintain a huge bash repository and have tried to use it, and it common makes mistakes. None of us maintainers have time to rewrite the scripts to match standards.

[-] 0x0@lemmy.dbzer0.com 7 points 1 day ago

I honestly think autocorrecting your scripts would do more harm than good. ShellCheck tells you about potential issues, but It's up to you to determine the correct behavior.

For example, how could it know whether cat $foo should be cat "$foo", or whether the script actually relies on word splitting? It's possible that $foo intentionally contains multiple paths.

Maybe there are autofixable errors I'm not thinking of.

FYI, it's possible to gradually adopt ShellCheck by setting --severity=error and working your way down to warnings and so on. Alternatively, you can add one-off #shellcheck ignore SC1234 comments before offending lines to silence warnings.

[-] UndercoverUlrikHD@programming.dev 4 points 20 hours ago

For example, how could it know whether cat $foo should be cat "$foo", or whether the script actually relies on word splitting? It's possible that $foo intentionally contains multiple paths.

Last time I used ShellCheck (yesterday funnily enough) I had written ports+=($(get_elixir_ports)) to split the input since get_elixir_ports returns a string of space separated ports. It worked exactly as intended, but ShellCheck still recommended to make the splitting explicit rather than implicit.

The ShellCheck docs recommended

IFS=" " read -r -a elixir_ports <<< "(get_elixir_ports)"
ports+=("${elixir_ports[@]}")
[-] stetech@lemmy.world 3 points 1 day ago

Then you’ll have to find the time later when this leads to bugs. If you write against bash while declaring it POSIX shell, but then a random system’s sh doesn’t implement a certain thing, you’ll be SOL. Or what exactly do you mean by “match standards”?

this post was submitted on 05 Mar 2025
1529 points (100.0% liked)

Programmer Humor

21016 readers
1242 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev