On 11/13/19 10:59 AM, Shaun Crampton wrote: > But the commands in the subshell execute inside a different shell > execution context so they shouldn't have > their own set -e context (Section 2.12)? > > I don't see where the spec says that the subshell has to inherit the > and/or list-ness of the > parent context. Section 2.12 doesn't mention that as being one of the > things that a subshell inherits > (and unless I'm missing a good use-case, it seems like a pretty > useless thing to inherit in a subshell > or a function that happens to be called on the LHS of an and/or). You're trying to defend the behavior you *want* set -e to have, even though many people rely on set -e having the behavior it does, indeed, have. Why do you require that yet another behavior change be made, so that it is even harder to know what set -e will do across various shells, and across various *versions* of a shell?
set -e already has more than enough exceptions to every single rule it ever had. It's a collection of inchoate nonsensical lexical rules. Don't use it, for all the reasons enumerated here: https://mywiki.wooledge.org/BashFAQ/105 Everyone will be much happier if they just don't use set -e, and, instead, implement actual real error handling that a) works, b) does what they expect in their own special snowflake case. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
