3 ms·
You can go a really really long way, with a script that will work everywhere, with just set -e and aborting at the first error. Better yet, 'bash unofficial st
by superq 2y ago
You can go a really really long way, with a script that will work everywhere, with just set -e and aborting at the first error.
Better yet, 'bash unofficial strict mode':
set -euo pipefail
IFS=$'\n\t'
- shawn_w 2y agoThat has lots of issues. See https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail for some.
- sgarland 2y agoIt does, yes, but IME if you can get people who aren’t familiar with shell to use it, it prevents more problems than it solves on the whole. Then again, so does enforcing passing shellcheck in CI.
- citrin_ru 2y agoOne can made arguments both for and against `set -e`. Over may carrier I've seen many shell scripts: The most common case is no `-e` and no explicit error/status checks for most commands. It's unreliable and such scripts is one of reasons why shell got it's bad reputation (and criticized by coders using languages where an unhanded exception would terminate a program). In my own scripts I often use `-e` (but not always as it is a tradeoff). If you unfamiliar with shell `-e` also could cause problems. But `-e` is not magic which makes a script better, one have to know how it works. The option author of this article advocates (no `-e` but explicitly check every command which could fail) is the least common IMHO. Unless the scripts calls just 1-2 commands it's tedious and the resulting script is harder to read. May be you can find such style in some opensource projects but I've never seen such scripts at work.