4 ms·

Sure, this is a good idea (from the proposed patch): + # safety check + [ "${diaspora_user_home}" != "" ] || exit 1 + [ "${dia

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.

LyndsySimon 10y ago
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.
- a3n 10y ago
  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.
ctrlrsf 10y ago
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
peff 10y ago
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.
- pixelbeat 10y ago
  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.html 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 http://www.pixelbeat.org/programming/sigpipe_handling.html

LyndsySimon 10y ago

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.

a3n 10y ago
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.

ctrlrsf 10y ago

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

peff 10y ago

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.

pixelbeat 10y ago
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.html 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 http://www.pixelbeat.org/programming/sigpipe_handling.html