linuxmemes

It is different in spoken form, written form (chat) and written as a post (like here).

In person, you get a reaction almost immediately. Written as a short chat, you also get a reaction. But like this is more of an accessibility thing rather than the joke not being funny. You know, like those text descriptions of an image (usually for memes).

I really recommend that if you haven't, that you look at the Bash's man page.

It's just amazing.

God I love bash. There's always something to learn.

my logical steps

• #! yup
• if sure!
• [[ -z makes sense
• ${1:-} WHAT IN SATANS UNDERPANTS.... parameter expansion I think... reads docs ... default value! shit that's nice.

it's like buying a really simple generic car then getting excited because it actually has a spare and cupholders.

That's good, but if you like to name your arguments first before testing them, then it falls apart

#!/bin/bash
set -euo pipefail

myarg=$1

if [[ -z "${myarg}" ]]
then
  echo "we need an argument!" >&2
  exit 1
fi

This fails. The solution is to do myarg=${1:-} and then test

Edit: Oh, I just saw you did that initialisation in the if statement. Take your trophy and leave.

Yeah, while -e has a lot of limitations, it shouldn't be thrown out with the bathwater. The unofficial strict mode can still de-weird bash to an extent, and I'd rather drop bash altogether when they're insufficient, rather than try increasingly hard to work around bash's weirdness. (I.e. I'd throw out the bathwater, baby and the family that spawned it at that point.)

This is why I made the reference to Go. I honestly hate Go, I think exceptions are great and very ergonomic and I wish that language had not become so popular. However, a whole shitload of people apparently disagree, hence the popularity of Go and the acceptance of its (imo) terrible error handling. If developers don't have a problem with it in Go, I don't see why they'd have a problem with it in Bash. The error handling is identical to what I posted and the syntax is shockingly similar. You must unpack the return of a func in Go if you're going to assign, but you're totally free to just assign an err to _ in Go and be on your way, just like you can ignore errors in Bash. The objectively correct way to write Go is to handle every err that gets returned to you, either by doing something, or passing it up the stack (and possibly wrapping it). It's a bunch of bubbling up. My scripts end up being that way too. It's messy, but I've found it to be an incredibly reliable strategy. Plus, it's really easy for me to grep for a log message and get the exact line where I encountered an issue.

This is all just my opinion. I think this is one of those things where the best option is to just agree to disagree. I will admit that it irritates me to see blanket statements saying "your script is bad if you don't set -euo pipefail", but I'd be totally fine if more people made a measured recommendation like you did. I likely will never use set -e, but if it gets the bills paid for people then that's fine. I just think people need to be warned of the footguns.

EDIT: my autocorrect really wanted to fuck up this comment for some reason. Apologies if I have a dumb number of typos.

The issue with set -e is that it's hideously broken and inconsistent. Let me copy the examples from the wiki I linked.

Or, "so you think set -e is OK, huh?"

Exercise 1: why doesn't this example print anything?

#!/usr/bin/env bash
set -e
i=0
let i++
echo "i is $i"

Exercise 2: why does this one sometimes appear to work? In which versions of bash does it work, and in which versions does it fail?

#!/usr/bin/env bash
set -e
i=0
((i++))
echo "i is $i"

Exercise 3: why aren't these two scripts identical?

#!/usr/bin/env bash
set -e
test -d nosuchdir && echo no dir
echo survived 

#!/usr/bin/env bash
set -e
f() { test -d nosuchdir && echo no dir; }
f
echo survived

Exercise 4: why aren't these two scripts identical?

set -e
f() { test -d nosuchdir && echo no dir; }
f
echo survived

set -e
f() { if test -d nosuchdir; then echo no dir; fi; }
f
echo survived

Exercise 5: under what conditions will this fail?

set -e
read -r foo < configfile

And now, back to your regularly scheduled comment reply.

set -e would absolutely be more elegant if it worked in a way that was easy to understand. I would be shouting its praises from my rooftop if it could make Bash into less of a pile of flaming plop. Unfortunately , set -e is, by necessity, a labyrinthian mess of fucked up hacks.

Let me leave you with a allegory about set -e copied directly from that same wiki page. It's too long for me to post it in this comment, so I'll respond to myself.

Your scientists were so preoccupied with whether they could, they didn’t stop to think if they should

Yeah, I had a silly hack for that. I don't remember what it was. It's been 3-4 years since I wrote bash for a living. While not perfect, I still need to know if a pipeline command failed. Continuing a script after an invisible error, in many cases, could have been catastrophic.