I'd rather both have this option and have it work reliably. It's ridiculous that

    export VAR=$(cmd1 | cmd2)

does not count as a pipefail when cmd1 or cmd2 fail but

    VAR=$(cmd1 | cmd2)

does, so the "correct" way to set an environment variable from a pipeline's output is actually

    VAR=$(cmd1 | cmd2)
    export VAR

Pipefail is useful and very hard to emulate on pure POSIX; you need to create named fifos, break the pipeline into individual redirections and check for error on each line.

And that is fine; but sometimes you want to treat a pipeline as a "single command" and then you can use pipefail to abort the pipeline on error. Then you can handle the error at the granularity of the entire pipeline without caring which part failed.

Lastly, I am confused as to the "silent" failures; maybe you are thinking of combining this with `set -e`? Then yes, that is bad and I recommend against the combination; but then again, I and most advanced scripters recommend against shotgunning `set -e` in the first place. Use it in specific portions of the script when appropriate, and use proper error handling otherwise.

Why does `set -e` make a pipeline fail silently?

`set -e` makes the script abort and is often used in lieu of proper error handing:

  set -e
  command
  command [fails]
  command

Whether the above reports error or not depends on the command; when you have a pipeline failing in the above way, it is even sneakier:

  set -e
  command
  command | command | command [fails]
  command

You are reliant on all commands in the pipeline being verbose about failure to signal error.

None of the above is advisable. The advisable code is

  error_handler() { proper error handling; }

  command || error_handler "parameter"
  command || error_handler "parameter"

  { command | command | command; } || error_handler "parameter"

  {
  set -e
  exceptional section that needs to be bailed out
  set +e
  }

  command || error_handler "parameter"

Error handling like that makes sense if you’re writing a program. But if you just want a script for an automation, `set -e` is enough.

It is not; Greg's wiki further explains why, if the silent failure problem above is not enough reason.

Gee, imagine if shells with errexit option enabled wrote some diagnostic output to stderr before exiting. "Add your own error checking instead", how do I check which piece of pipeline has failed, exactly? The PIPESTATUS variable is bash-specific and was not standardized.

? Why are you replying to me? My position was pretty clear:

"Pipefail is useful and very hard to emulate on pure POSIX; you need to create named fifos, break the pipeline into individual redirections and check for error on each line.

And that is fine; but sometimes you want to treat a pipeline as a "single command" and then you can use pipefail to abort the pipeline on error. Then you can handle the error at the granularity of the entire pipeline without caring which part failed."

By the way, I never script in Bash; I only script in POSIX primitives using dash as my executable.