> 1. Pipefail is a bashism, and doesn't exist on Ubuntu's /bin/sh or Busybox /bin/sh (common on embedded Linux systems)

I wasn't suggesting for a generic posix shell. It's explicitly for bash.

If you're going to dumb down to pure posix, it's even more painful as you can't even have local function variables.

> 2. Pipefail invalidates some common shell patterns like "grep _something_ | xargs -r CMD".

That type of situation is the exception, not the rule. The more common situation is "foo some-input.txt | bar" and you want it to fail if foo fails.

> Pipefail is nice in some circumstances for sure. But it's probably not great advice to automatically copypasta into the top of every shell-script.

I'd much rather have that type of failure than an inadvertent continuation of a script when something early in a pipeline failed.

I don't agree on -e: see my comment higher up in the thread. It might be ok if you're hyper-aware, but recommending it to others will leave them baffled and confused in situations like that in my example where a non-zero exit is within the bounds of normal behavior of the script.

> If I get good enough at bash, will it get better?

Bash itself will not get better because you'll be stuck writing scripts targeting some ancient version to ensure wider compatibility.

It's still a powerful skill to develop. It's a sweet spot between a one-off shell pipeline and something that involves actual logic.

Bash scripts should not be used for their logic. Think of them as a way to document a series of commands that you do not want to manually type. That can be including long argument names, generating includes or classpaths, or generating log file names based on the current time.

A good rule of thumb is if your script involves any if-statement other than parameter validation or basic on-success-of-x-do-y, it probably should be in a real language.