Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: command substitution is stripping set -e from options Date: Sat, 3 Oct 2015 15:52:40 -0400 Organization: ITS, Case Western Reserve University Lines: 27 Approved: bug-bash@gnu.org Message-ID: References: <560D83DA.9020405@redhat.com> <20151002122925.GK25574@eeg.ccf.org> <20151002132221.GL25574@eeg.ccf.org> Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1443902016 12892 208.118.235.17 (3 Oct 2015 19:53:36 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org, chet.ramey@case.edu To: Greg Wooledge , Christoph Gysin Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <20151002132221.GL25574@eeg.ccf.org> X-Junkmail-Whitelist: YES (by domain whitelist at mpv2.tis.cwru.edu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 129.22.105.37 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11578 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, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/