Hacker News Reader

Comment by codys | Hacker News Reader

On point 2: indeed, given that they are restricting themselves to bash, I would have expected a note of `set -eu -o pipefail`, at least. `-x` (tracing), isn't appropriate for many scripts, though.

On point 3: `: ${FOO:-some default value}` is the typical pattern for ensuring a default value is set.

View on HN

I tend to avoid `set -e`. To borrow the Python adage: "explicit is better than implicit". In shell it translates to "if you need error handling, add it where necessary".

See http://mywiki.wooledge.org/BashFAQ/105 for some (most) of the pitfalls.

"Errors should never pass silently." is more relevant for `set -e`

Except they do even with `set -e`. Especially if you forget to/can't set `pipefail` (which is bash-specific).

Or consider the last example from the wiki link above:

  set -e
  f() { local var=$(somecommand that fails); }
  f    # will not exit

Yep, it is inconsistent:

    $ ( set -e; foo() { f=$(false); }; foo ; ); echo $?
    1
    $ ( set -e; foo() { local f=$(false); }; foo ; ); echo $?
    0
    $ ( set -e; foo() { local f; f=$(false); }; foo ; ); echo $?
    1

However, it is still better to use -e to catch errors early.

Except `set -e` (along with pipefail) is exactly what prevents you from implicitly catching failures, forcing you to be explicit (rather than implicit) with your error-handling, which is closer to how Python itself deals with unhandled exceptions. It has its limitations and caveats, and you can accomplish the same goals somewhat differently, but it is inaccurate to say that using `set -e` is tantamount to doing things implicitly.

Ah yes, I put `-x` by mistake there!

Reply on news.ycombinator.com