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,…
Shell script best practices, from a decade of scripting things
171–180 of 500 posts
Re: Shell script best practices, from a decade of scripting things
#172Do you guys think that Shell scripting will still be around in 20 years?
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
#173Unfortunately, `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
#174Credibility gone.
Re: Shell script best practices, from a decade of scripting things
#175Earlier 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.
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
#176I'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,…
Re: Shell script best practices, from a decade of scripting things
#177More 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…
Re: Shell script best practices, from a decade of scripting things
#178> Use bash. Yeaah, closes tab .
Re: Shell script best practices, from a decade of scripting things
#179Template in article is awful. It's better to use this one, which is a real CLI tool: https://github.com/vlisivka/bash-modules/blob/master/bash-mo...
Re: Shell script best practices, from a decade of scripting things
#180This 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