3 ms·

Good rules overall, we follow similar guidelines. Any comments on: * readonly - describing these in library scripts is a bit dangerous since the readonly is no

Good rules overall, we follow similar guidelines. Any comments on: * readonly - describing these in library scripts is a bit dangerous since the readonly is not specific to the file. So, unless you have some namespacing pattern for globals, this will bite you * I didn't see any recommendation but always start with set -eux -o pipefail. set -e has it's own set of pitfalls but it's best to learn what the pitfalls are and work with it :-) It helps in the long run. * When using set -u, use the FOO={FOO:-} syntax to initialize defaults for all your env vars.

codys 10y ago
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.
- ymse 10y ago
  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 http://mywiki.wooledge.org/BashFAQ/105 for some (most) of the pitfalls.
  - d0mine 10y ago
    "Errors should never pass silently." is more relevant for `set -e`
    - ymse 10y ago
      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
      - lisivka 10y ago
        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.
  - stefco 10y ago
    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.
- the_common_man 10y ago
  Ah yes, I put `-x` by mistake there!

codys 10y ago

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.

ymse 10y ago
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 http://mywiki.wooledge.org/BashFAQ/105 for some (most) of the pitfalls.
- d0mine 10y ago
  "Errors should never pass silently." is more relevant for `set -e`
  - ymse 10y ago
    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
    - lisivka 10y ago
      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.
- stefco 10y ago
  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.
the_common_man 10y ago
Ah yes, I put `-x` by mistake there!