Hacker News Reader

Comment by wyldfire | Hacker News Reader

Sure, this is a good idea (from the proposed patch):

    +        # safety check
    +        [ "${diaspora_user_home}" != "" ] || exit 1
    +        [ "${diaspora_home}" != "" ] || exit 1

... but this is key IMO:

    +# Abort if any unbound variables are used
    +#set -u

I often use "set -euo pipefail" in my bash scripts. It does come with some caveats, though.

View on HN

I use the long form so others reading script that may not be familiar with set options gets a hint of what's going on.

At the top of each file with a brief comment I add:

  set -o errexit
  set -o nounset
  set -o pipefail

To be fair, the proposed patch says on the box that it's "completely untested". The author seems to be politely saying that the package is a hot mess, and my impression was that they weren't willing to put any more time into it.

My impression was that the submission of the untested patch ("testing welcome") was that it was a fast first step in collaboratively fixing the issue.

Using "set -e" with pipefail is racy because of SIGPIPE. For example, if you do this:

    some_command | head

Then depending on timing, `some_command` _may_ generate all of its output and stuff it into the pipe, exiting successfully. Or `head` may get the lines it needs and close the pipe, causing `some_command` to exit with SIGPIPE. Using pipefail makes the whole pipeline fail, and then `-e` terminates the script.

And it only happens sometimes.

That really is a bash bug IMHO I've discussed this with upstream bash at http://lists.gnu.org/archive/html/bug-bash/2015-02/msg00052....

I've some general notes on SIGPIPE mishandling at http://www.pixelbeat.org/programming/sigpipe_handling.html

Reply on news.ycombinator.com