Re: command substitution is stripping set -e from options
> Chet can give the definitive answer, but my take is that it's a huge > surprise to someone writing a function independent of the script, or > using a function that was written independently of the script. If the > function does not expect set -e to be in effect (which is not the default, > and is not done in any sane environment, so why would anyone EXPECT it?) > then it may have been written to work in a normal environment, and will > fail in a set -e environment. Yes, obviously you can't just source other bash files and assume they work with set -e (or set -u for that matter). But if I do I still have the option of consciously disabling said options with set +e. > I have many examples of commands that surprisingly explode and set your > house on fire when run in a set -e environment, but which work perfectly > well in a regular environment. See http://mywiki.wooledge.org/BashFAQ/105 Thanks for that excellent resource! Maybe I spent too much time with bash scripts, but I'm already aware of all those corner cases. Yes they are not pretty, but for each of them there is a simple workaround. Tools like shellcheck will even warn you about some of them. The behaviour I describe seems to fall in a different category though. Switching to posix mode has all kinds of other side effects, so I don't think that's a valid workaround. And it seems that the code to inherit set -e is already there, just not enabled by default. This seems to cause behaviour that is counter-intuitive IMO. Chris
Re: command substitution is stripping set -e from options
On 10/2/15 9:22 AM, Greg Wooledge wrote: > On Fri, Oct 02, 2015 at 03:53:42PM +0300, Christoph Gysin wrote: >> I'm still curious as to why set -e is stripped in the first place? > > Chet can give the definitive answer, but my take is that it's a huge > surprise to someone writing a function independent of the script, or > using a function that was written independently of the script. It's been over 20 years, and we weren't as detailed with our change logs back then, but I imagine the rationale was similar to the above with the addition of something like the following: The parent shell (the one that enabled -e) should be the one to make the decision about whether or not the shell exits. The exit status of the command substitution doesn't make a difference except in one special case, so inheriting errexit and exiting (possibly prematurely) doesn't really help the parent decide whether or not to exit. Now, of course, it's been more than 20 years, and backwards compatiblity is a concern. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
