Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail From: Greg Wooledge Newsgroups: gnu.bash.bug Subject: Re: command substitution is stripping set -e from options Date: Fri, 2 Oct 2015 09:22:21 -0400 Lines: 15 Approved: bug-bash@gnu.org Message-ID: References: <560D83DA.9020405@redhat.com> <20151002122925.GK25574@eeg.ccf.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1443794710 15967 208.118.235.17 (2 Oct 2015 14:05:10 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: Christoph Gysin Envelope-to: bug-bash@gnu.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 139.137.100.1 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:11576 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. 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. 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