Yet another toot of mine getting a lot of boosts because I used someone else's content. Give Julia some love

@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!

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?

Can you describe the whole setup? Can you check if e.g. your bashrc doesn't happen to have `set -e`?

@tamtararam 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:

(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
-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

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`...

Sign in to participate in the conversation – a Fediverse instance for & by the Chaos community