New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should bash strict mode be recommended as good practice? #30
Comments
👍 I think that's definitely appropriate for an intermediate audience. |
👍 from me too. Makes me wonder whether there could be a shell-scripting lesson here as well, including this, using functions, if...then statements. |
I'm -0.5 on a shell scripting lesson: by the time you need conditionals
and functions, you should have switched to a language with proper data
structures.
|
I completely agree, and I keep saying this to many people on our lab, but getting them to give up the (false) comfort of their bash skills and scripts, and take a course in python/R/whatever that gets them to the same level of comfort, is not something I am very successful with (I need more power ;-) ). Maybe a lesson on 'if you (would like to) do this in a shell script, the equivalent python script would look like this'? |
@gvwilson @lexnederbragt Agree with you in principle, however there are many use cases where shell scripts are still the better choice: for running a series of commands (executables) you should really not use Python (in particular not |
Hmmm... I am more and more convinced that a Makefile is the better way to go in such a case. But that has another set of drawbacks: not easy to learn, less transparent what is being run... |
Sure, as soon as it gets slightly more complex and you have interdependencies a Makefile is definitely superior. But there is that narrow use case for bash scripts and for that imho strict mode is very important. |
If we recommend strict mode, we should note it could break some workflows. I recently ran into an issue where I was some text manipulation in a subshell that can fail which was okay for the toolchain, but when I added strict the toolchain would exit if that subshell call failed. @gvwilson When you work on a toolchain that exclusively relies on manipulating files and chaining together other command line tools, what do you suggest if not bash? |
@gdevenyi You can always append |
Getting back to @peterjc's initial comment of using
|
Also consider |
I would recommend this version: #!/usr/bin/env bash
SOURCED=false && [ "$0" = "$BASH_SOURCE" ] || SOURCED=true
if ! $SOURCED; then
set -euo pipefail
IFS=$'\n\t'
fi In this way you can safely source the script, if needed, without polluting your shell. |
@CristianCantoro Interesting idea but I see two problems with it: it may fail if run with non bash shell or if you already had |
@ssbarnea to be fair this is the bash strict mode, so I would say that using However, you are absolutely right, I didn't notice this issue it until because it manifests itself only if you source the script directly from a non-bash shell and you have If you are using This would be a fix: #!/usr/bin/env bash
SOURCED=true
if [ ! -z "${BASH_SOURCE+x}" ]; then
SOURCED=false && [ "$0" = "$BASH_SOURCE" ] || SOURCED=true
fi
if ! $SOURCED; then
set -euo pipefail
IFS=$'\n\t'
fi A little bit more verbose, and it still does not support other shells, though |
Should bash strict mode be recommended as good practice? See http://redsymbol.net/articles/unofficial-bash-strict-mode/ which uses:
Personally I use
set -e
most heavily, and generally just use the one lineset -euo pipefail
after the hash-bang.Originally raised as swcarpentry/shell-novice#251 but we agreed it was too advanced for the shell novice lesson.
The text was updated successfully, but these errors were encountered: