Who is responsible for providing `set -o pipefail`

Question

I want strict mode in my scripts. I would also appreciate portability.

set -o pipefail seems compulsory. Yet shellcheck(a static linter) is unhappy that "In POSIX sh, set option pipefail is undefined".

Is it correct? If so, is this a bash solely feature or is it rather prolific?

Answer 1

The pipefail option comes from ksh93 and is also present in a few other shells. It was added:

• to ksh93g released in 1998
• to bash 3.0 released in 2004
• to busybox ash in 2009
• to busybox hush in 2010
• to mksh r46 released in 2013
• to zsh 5.0.3 released in 2013
• to yash 2.42 released in 2016
• to NetBSD sh in 2017
• to FreeBSD sh in 2019
• to OpenBSD sh in 2020

A request to add it to the POSIX standard was submitted in 2013 and a resolution accepted in 2019. So it will be in the next major revision of the standard due soon.

It will still probably take some more time for remaining implementations (mostly dash, bosh and ksh88-based shells) to add support for it. After which the "EOL" clock will start ticking and 10 years later you'll be able to assume all sh implementations on currently supported systems will support it.

Answer 2

The pipefail shell option is specific to a number of shells that shellcheck claims to support¹. You can use this shell option and be portable, if by "portability" you assume that any target system has a shell that supports it (and any other constructs that you may be using). This is the same type of "portability" that you get with any other specific scripting language.

The shellcheck linter will complain if it finds set -o pipefail in a shell script that is a sh script, since it's currently not supported by POSIX sh.

To ensure that your script is a script interpreted by the bash shell (or any specific shell that you are coding for), the script should have a #!-line pointing to the correct shell interpreter, e.g.,

#!/bin/bash

or possibly

#!/usr/bin/env bash

or something similar.

With a proper #!-line that additionally indicates that the script will be interpreted by a particular shell that is not sh, the shellcheck linter will not complain about you setting the pipefail shell option in your script.

If you don't use a #!-line in your scripts, then you should consider doing so (or always run your scripts with an explicit interpreter on the command line). Meanwhile, the shellcheck command line tool can be told to switch to mode using its -s (or --shell=) option:

shellcheck --shell=bash myscript

---

¹_{I suspect that shellcheck has a "POSIX sh mode" and an "other mode" to support bash, dash, and ksh (shellcheck does not claim to support zsh). The pipefail shell option is documented to work with bash, and ksh. The zsh shell has a PIPE_FAIL shell option that can be set in the same way. The dash shell does not support the option, but if the #!-line mentions dash, shellcheck won't complain about pipefail.}

Answer 3

What do you want to happen when script runs on shell that doesn't support pipefail?

Turns out order matters on some shells but is not the whole story. bash cares about order even within single set command — it continues on set -o NoSuchOption -e vs. exits on set -e -o NoSuchOption.

• 👉 If you want to exit if pipefail is not supported, set -e; set -o pipefail looks enough. (the shells I tried print an error message in such case)

But it gets worse: bash --posix (== /bin/sh on many systems) and dash exit immediately on set -o NoSuchOption even without set -e anywhere!
bash can be appeased by set -o NoSuchOption || true (not sure why that works) but not dash, it really crashes on the spot.

• 👉 If you want to continue running on all shells, even ones that don't support pipefail, it looks like you must first probe whether it's supported. This is best I came up with for bash, bash --posix and dash, no idea if it's portable yet more other shells:

set -e
trap '
  s=$? p=("${PIPESTATUS[@]}")
  echo "$0: Error ${p[*]} on line $LINENO: $BASH_COMMAND" 1>&2
  exit $s
' ERR 2>/dev/null || true

set -o | grep -q pipefail && set -o pipefail
echo cont1

true | sh -c 'exit 2' | false | true
echo cont2

true | sh -c 'exit 3'
echo cont3

Here bash (whether posix mode or not) stops on the mid-pipeline errors:

cont1
t.sh: Error 0 2 1 0 on line 13: true

while dash doesn't support pipefail, only aborted where right-most command exited non-0:

cont1
cont2

dash also doesn't support ERR traps (https://stackoverflow.com/a/58297505/239657 tries to approximate it but not well enough imho)

• ❓ but is this a good idea? You risk writing code that assumes pipefail is in effect but it might not be; and you can't explicitly check $PIPESTATUS array, e.g. dash doesn't have it either.

  So this was an interesting exercise, but I'd recommend to exit where pipefail is unsupported. And IMHO once you care about such things you want to require bash specifically — it gives you other goodies too like ERR, printing stack traces with $BASH_SOURCE, $BASH_LINENO, $FUNCNAME arrays etc...