Live data from Hacker News

Shell script best practices, from a decade of scripting things

sharats.me

171–180 of 500 posts

Re: Shell script best practices, from a decade of scripting things

#171

I'm not convinced about having shell scripts end with ".sh" as you may be writing a simple command style script and shouldn't have to know or worry about what language it's using. I'm a fan of using BASH3 boilerplate: https://bash3boilerplate.sh/ It's standalone, so you just start a script using it as a template and delete bits that you don't want. To my mind, the best feature is having consistent logging functions,…

TIL about bash3boilerplate, thanks! Going to check it out.

Re: Shell script best practices, from a decade of scripting things

#172
post #95

Do you guys think that Shell scripting will still be around in 20 years?

Most definitely.

It occupies a sweet spot of being ubiquitous, quick to write/deploy and naturally interfaces with OS commands. It's the glue that holds unixes/linuxes together.

Re: Shell script best practices, from a decade of scripting things

#173
> set -o errexit

Unfortunately, `errexit` is fairly subtle. For example

    [ "${some_var-}" ] && do_something
is a standard way to `do_something` only when `some_var` is empty. With `errexit`, naively, this should fail, since `false && anything` is always false. However, `errexit` in later versions of Bash (and dash?) ignore this case, since the idiom is nice.

However! If that's the last line of a function, then the function's return code will inherit the exit code of that line, meaning that

    f(){ [ "${some_var-}" ] && do_something;}; f
will actually trigger `errexit` when `some_var` is empty, despite the code being functionally equivalent to the above, non-wrapped call.

Anyway, there are a few subtleties like this that are worth being aware of. This is a good, but dated, reference: https://mywiki.wooledge.org/BashFAQ/105

Re: Shell script best practices, from a decade of scripting things

#175
post #126

Earlier quoted context omitted.

> obviously you wouldn't just run something from the internet without checking it first This died a long time ago with the pervasive use of NPM and PIP and the likes. Most developers probably run a lot of random unchecked shit all the time with local user privileges today without a blink. Somehow people are ready for all this, but are still afraid to run a random shell script from the internet. I guess this fear is o…

If you're committed to being an idiot no amount of rules of thumb will save you. Not understanding what you use is one facet of being committed to that.

But people don't live in a vacuum. They live in an ecosystem, are subjected to it and contribute to it.

If I contribute to Nextcloud or write an app for it, I need to run npm. If I want to run PeerTube, I need to run npm. They both pull a shitload of dependencies I can't possibly review.

I personally avoid building anything using NPM and advocate for fewer / no dependencies, or for using dependencies packaged by reputable entities like Debian, but what can I do? I can't build everything myself.

Am I committed to being an idiot?

Re: Shell script best practices, from a decade of scripting things

#176

I'm not convinced about having shell scripts end with ".sh" as you may be writing a simple command style script and shouldn't have to know or worry about what language it's using. I'm a fan of using BASH3 boilerplate: https://bash3boilerplate.sh/ It's standalone, so you just start a script using it as a template and delete bits that you don't want. To my mind, the best feature is having consistent logging functions,…

This is fantastic! I'm going to start using this as the baee for all my scripts, and will also start using shellcheck (on CI as well.)

Re: Shell script best practices, from a decade of scripting things

#177
post #128

More opinions 1. Bash shouldn't be used, not because of portability, but because its features aren't worth their weight and can be picked up by another command, I recommend (dash) any POSIX complaint shell (bash --posix included) so you aren't tempted to use features of bash and zsh that are pointless, tricky or are there for interactivity. Current POSIX does quite well for what you would use shell for. 2. Never use…

POSIX complaint shell? I'm intrigued by that.

Re: Shell script best practices, from a decade of scripting things

#180
post #112

This is not a best practices guide, please look forward to: https://mywiki.wooledge.org/BashGuide For example, using cd "$(dirname "$0")" to get the scripts location is not reliable, you could use a more sophisticated option such as: $(dirname $BASH_SOURCE)

And THIS is the primary source of my furious hate in my toxic love-hate relationship with bash. Guy is writing bash FOR 10 FUCKING YEARS and still apparently doing it wrong in 10 letter oneliner. When it comes to bash search for even simplest command/syntax always ALWAYS leads to stackoverflow thread with 50 answers where bash wizards pull oneliners from sleeves and nitpick and argue about various intricancies

It's a case of knowing the wooledge website (and working with shellcheck), or not. Picking snippets on stackoverflow will probably do more harm than good, tbh.
Post reply on HN