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?

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

@tamtararam

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

@tamtararam

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
# }}}

@tamtararam

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
chaos.social

chaos.social – a Fediverse instance for & by the Chaos community