Elegant Bash Conditionals

There will be people - seasoned professional developers, even - reading these languages that don't know the first thing about them!

`[` is one of those things that are second nature for seasoned bash people but that are utterly ungoogleable by a bash beginner. Beginners don't know `[` is an executable, and it would never occur to them to `man [`. It can become quite the rabbit hole to figure out that there's also `[[` (which is NOT an executable), that `[ a > b ]` is very very different from `[[ a > b ]]`, etc.

So do these people a favor and put the `if` there so they at least have some hope of stumbling upon a stack overflow post talking about some of this stuff.

Like so:

  # Download the binary
  wget --quiet --output-document /usr/local/bin/mybinary "$download_url" || {
    error 'Failed downloading the CLI'
    exit 1
  }

  debug "Making CLI executable"
  # Make it executable
  chmod +x /usr/local/bin/mybinary || {
    error 'Failed making CLI executable'
    exit 1
  }

https://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7...

So how does `if [ <condition> ]` work then? Is it some kind of special case? No! The way it works is that there's an executable named `[` in UNIX that that takes the condition expression as arguments, and returns "success" or "failure" depending on if the condition evaluates to true. It's right there in the filesystem at /bin/[

Now, some sticklers might argue that maybe not the greatest idea to spawn a process every time you need to evaluate an if statement, but I really do admire the UNIX purity of it: of COURSE that's how bash conditionals work! This is UNIX, after all! Why add an expression parser/evaluator to bash when you can just have it's own process for that? Do one thing and do it well!

Parameter expansion is a great way to simplify your code, but it can be obtuse to the casual reader. Setting a default variable using DEFAULT="${DEFAULT:-myvalue}" is a bit easier to understand than just ${DEFAULT:=myvalue}.

Read the dash manual and try to stick to just those features as it's almost entirely POSIX. Most scripts do not need to rely on bash functionality. https://linux.die.net/man/1/dash

If you find it will really simplify your life to have arrays, hashes/maps/dicts, a while loop reading from a subshell's output, etc, then use Bash and use those features. Otherwise, stick to POSIX semantics. You can do almost everything you need with parameter expansion, expr and other unix tools.

With any programming language, you should try to use the least amount of syntax and functionality possible to accomplish your goal, as long as it is readable, maintainable, and does not hide tricky behavior. Being verbose is always preferable to being hard to maintain; verbose and uncomplicated things can easily be simplified later.

Every developer has read enough if statements to understand if then else at a glance. Few people write enough bash scripts to have that same instant parsing of [[ condition ]] && cmd or [[ condition ]] || cmd, especially when intermingled.

I like the idea of cmd || { raise error; } that others have mentioned, but I hate the idea of using these in place of an if statement to save 2 lines.

>The echo command always exists [sic] with 0, so this propagates to exit if the first expression is truthful. (emphasis his)

In both bash and dash (and probably most), echo will fail if there is no stdout. E.g.:

    j.sh:
    echo hello && exit 2

    $ bash j.sh >&-
    j.sh: line 1: echo: write error: Bad file descriptor
    $ echo $?
    1

EDIT: Also note that not exiting the script could cause a flurry of cascading errors (likely permission errors in the article's example).

I really don't understand what is the problem with that simple if statement to receive this kind of reaction. :shrug:

    [ -r ~/.profile ] && . ~/.profile

Almost. The real way to do this is to check for the non-existence of the file as the “success” case and do the action via a || on failure.

Otherwise if you run in a strict mode with error on any unhandled non-zero command (set -e), you’ll exit the script with failure when the profile doesn’t exist:

    [[ ! -r ~/.profile ]] || . ~/.profile

cat ~/.profile && echo This is your profile || echo Failed to read profile

I think these are commonly called short-circuits. Using these with brackets too, in order to gain greater control or more complex comparisions is super useful if not aware of it.

A simple example would be something like:

# (foo && bar) && (bish || bash) && echo 0 || (echo "not bosh" && exit 1)

I'm no bash expert, just a sysadmin with a little dangerous knowledge, but constructing things that way just feels more natural (to me, at least, it's probably 'teaching your grandmother to suck eggs' to a proper bash hacker).

    -[ $EUID -ne 0 ] && { echo You must be root; exit 1 }
    +[ $EUID -ne 0 ] && { echo You must be root; exit 1; }

Explicit if [].. is more readable.

Chaining commands with && is better just accomplished by running `set -e` which you should be doing at the start of your script anyway.

And of course both of these are getting pretty close to the "if you have to Google what this bash syntax does, just write your script in Python" rule.

  [[ -f $input_file ]] || { echo "${input_file} does not exist"; exit 1; }

I get that the authors point was more focused on the conditional usage, but this seems like a pretty bad way to check if the user is root and isn’t really any more complicated than checking EUID = 0 or some of the other methods.

I have tended to use it more recently for vertical compactness, and in python because pylint doesn't like single-line if statements but happily tolerates "x or y".

   ( foo && bar && baz ) || ( fallback1 && fallback2 ) || echo 'Argh, even fallback failed!'

no closing `fi`, use multiline or single line, add an arbitrary number of elif statements. this only requires the short option is set in your z shell.

if (condition) { statements; } else { do other thing; }