On Wed, Sep 23, 2026, at 5:07 AM, R. Diez wrote: >>> I doubt that this is safe now, just because it's so easy for code >>> that won't work with those flags turned on to get written by >>> accident in the absence of these flags. > > What do you mean by "I doubt that this is safe now"? Do you mean that > Automake will probably generate standard recipes which break if I turn > those flags on? Or do you only mean that it is easy for me to write > unsafe code in my own makefile recipes?
I mean that I don't *know* whether Automake's standard recipes are reliable with -o errexit, but given that they haven't been tested that way, it seems wisest to me to assume they aren't. (although as said elsethread, apparently some Make implementations do already use sh -e so maybe they *have* been tested that way ... but it's not something I would feel safe relying on). I *also* mean that it would be easy for you to write unsafe code in your own recipes. >>> However, "make this safe and turn it on by default when the shell >>> supports it" seems like a desirable goal, and one I'd support for >>> both Automake and Autoconf. [...] > > I do not think that this goal is worth pursuing. Scripts which do not > check for errors are defective in my opinion Why do you say that the goal is not worth pursuing, if you believe that shell scripts (incl. make recipes) should be using these options? > My code does not have to be that portable, Bash is available all over > the place, and reasonable shells should have supported those flags > since many years now, much earlier than POSIX Issue 8. I would rather > lose some portability than write brittle scripts and effectively say > "if the shell does not support it, then silently ignore any eventual > errors". "lose some portability" is not what we do in auto*. "turn the options on whenever possible" gets you the benefits you want in contexts where they work, and degrades gracefully in contexts where they don't; that's what we do in auto*. > does Automake already generate standard recipes in one single, > possible very long, shell line? Yes it does (split with "; \" across many physical file lines); in many cases that's necessary because the standard recipes need to use shell variables. I'd like to see the largest of these moved to standalone shell scripts (poked into the build tarball by automake, much like it does now for things like 'install-sh') but that's a big project. >> The biggest problem with these options is that they are portability >> nightmares: the behaviour of "set -e / set -o errexit" is quite >> inconsistent between different shells (not to mention full of >> surprising gotchas if shell functions are used), Yikes! This is news to me, and it's something that should probably be documented more prominently in the autoconf manual's "portable shell programming" section (it *is* documented there, but buried deep in the discussion of 'set'). Without reading that very carefully, I can't tell how fatal all these inconsistencies would be to a quest to turn on -e mode in automake-generated *makefile recipes* specifically. (It sounds bad enough that it's probably a non-starter for configure scripts, particularly as those do use shell functions nowadays.) Can you hazard a guess? zw
