@tamtararam thank you for this. I forgot about it in recent scripts as it is something I never checked at all until this year.
It is an issue that some options are just for bash and I don't find the full set for dash.
I know that "-o" doesn't exist, but "-x", "-u" and "-e" exist perfectly.
@tamtararam Had no idea what this bit of boilerplate I'm used to seeing actually does. Awesome!
@tamtararam -eou is more memorable for me because it sounds like "eww don't do that".
@polychrome eou pipefail.
yesterday i learned that if you forget the pipefail, it just prints out all options on your system.
@tamtararam It's also important to keep in mind that set -e does *not* work on commands in subshells, e.g. if you set a variable with MYVAR="$(command_in_subshell)" and command_in_subshell returns with an error, the script will continue!
silly
@tamtararam yeah really, smh
silly
Also Julia Evans.
@tamtararam For that last one you can also use ´&&´ instead of pipe.
@tamtararam Or "How to work around a broken language".
@tamtararam Bash is annoying and confusing. I hate it.
@tamtararam https://mywiki.wooledge.org/BashFAQ/105 pipefail and -u is ok though
code snippet
@tamtararam You can error out on unset variables on a case by case basis by using `${var_name:?error message}`.
@tamtararam I have a serious and silly question. Why does my bash does things right by default without being implemented -e?
@terceranexus6
Can you describe the whole setup? Can you check if e.g. your bashrc doesn't happen to have `set -e`?
@tamtararam@chaos.social hmm, I tried using so-called strict mode many times, but too often it just resulted in a tedious debugging session with the script terminating at random place. Probably, I should have been using set -e and its friends from the start and don't rather slap it on a top of random scripts, but that's another story :)
the bash wiki gives mixed recommendations and some interesting examples to consider, they don't seem to be all artificial from my experience:
https://mywiki.wooledge.org/BashFAQ/105
(i.e. I really love to use [ -z "$*" ] && stuff inside one-line functions sometimes, which does not work as expected with set -e)
@tamtararam It's so easy to remember these. It's `set -e` for "Exit on Error" and `set -x` for "eXo". You just have to remember that it's Greek.
@freakazoid @tamtararam set -x is GREAT for debugging! It will just print every command it runs. Very helpful!
@rgegriff @tamtararam And now that I have finally figured out a mnemonic I'll be able to use `set -e` by itself without having to look up in the man page which is which.
@freakazoid @tamtararam I always remembered e for error, x for x-tremely verbose
@freakazoid @tamtararam
-a for "well, Actually, I think subprocesses should have access to the variables, too"
@tamtararam These do come with a lot of caveats (-e in particular can be a false sense of security because shell can't distinguish "error" from "false" and has to guess from context a lot); for a more general "try to disarm the sharpest bits of shell scripting", strongly recommend shellcheck (packaged for Debian, probably others) which is a linter that works...far, far better than should be possible for shell, really.
@tamtararam Oh, I had no idea one can screw themselves so badly with Bash...
That should catch most of the issues, but if you want to get real crazy, this is from the head of my bash scripts
#!/usr/bin/env bash
# SHELL OPTIONS {{{
set -o errexit # exit on error
set -o errtrace # exit on error inside function/subshell
set -o nounset # no undef vars. use ${VAR:-} for undef
set -o noglob # disable globbing
set -o pipefail # catch error on pipe fail
# set -o xtrace # turn on traces
# }}}
that said, `set -e` does not let programmers recover from error... often we need to `set +e` -> `if [[ "$?" != "0" ]]` -> `set -e`...
@tamtararam thank you very much!
Yet another toot of mine getting a lot of boosts because I used someone else's content. Give Julia some love