Robert Elz <[email protected]> writes: > Date: Thu, 11 Jun 2026 12:45:41 -0600 > From: Stan Marsh <[email protected]> > Message-ID: <[email protected]> > > | This paragraph is obviously nonsense, taken at face value. > > You're welcome to your opinion, but I meant what I said. > > | But in fact, properly interpreting it depends on two variables: > | > | 1) Are we talking about using -e as your primary (i.e., only) > | method of error handling or are we talking about using it as "last > | resort" - a handler for the truly unexpected? > > That actually makes no difference. Using -e at all, except in very > specialised scripts (I mean the way they are written, not what they do) > is almost always going to cause more problems than it solves. > > | 2) Are we operating in the world of actual reality, or is our > | orientation that of lecturing to newbies? > > There's certainly a bunch of the latter, but for this, the vast > majority of people who write sh code are newbies. There are > certainly people who actually understand -e (though even they can > sometimes be surprised by how it often doesn't do what was planned) > but they are a fairly small group. > > As a general rule, unless you have written a shell, or worked on the > code for one for years, you probably don't really understand -e (many > people believe they do, most of them are wrong.) > > Just don't use it. Really, just don't. > > If you need a shell option to help make your code safer, by all > means, turn on -u. That one works in a predictable, and fairly > easy to understand, way (it isn't an alternative to -e of course, > there isn't one of those).
For others reference, the issues with 'set -e' that kre mentions (or at least some of them) are documented in the Autoconf manual [1]. Collin [1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.73/autoconf.html#set
