Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: -e does not take effects in subshell Date: Fri, 21 Aug 2015 07:52:46 -0400 Lines: 36 Approved: bug-bash@gnu.org Message-ID: References: <20150811135056.GD4309@eeg.ccf.org> <55CC26A7.10000@redhat.com> <55D39A71.2030109@tlinx.org> <87mvxo5mme.fsf@igel.home> <55D3B22E.9040507@tlinx.org> <20150819124214.GL4309@eeg.ccf.org> <55D4FBEA.10602@tlinx.org> <55D6693F.5070003@case.edu> <55D672E8.70608@tlinx.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 1440158011 24765 208.118.235.17 (21 Aug 2015 11:53:31 GMT) X-Complaints-To: action@cs.stanford.edu Cc: Greg Wooledge , "bug-bash@gnu.org" , chet.ramey@case.edu To: Linda Walsh Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 In-Reply-To: <55D672E8.70608@tlinx.org> X-Junkmail-Status: score=10/50, host=mpv5.cwru.edu X-Junkmail-Whitelist: YES (by domain whitelist at mpv1.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.36 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:11407 On 8/20/15 8:38 PM, Linda Walsh wrote: > > > Chet Ramey wrote: >>> The earlier spec had -e only exit a script if a *simple* (external) >>> command failed. It didn't include builtins nor functions. >> >> This is not; builtins and functions are simple commands. > --- > The builtins are _complex_ binary blobs that replace external commands. > > Functions are a collection of many commands. They are not a single, > simple statement. I remember using their return value in some cases. `Simple command' is a specific term with a specific meaning. It doesn't have anything to do with perceived implementation complexity. > > With the change, I couldn't run a func and have it return the > value in $? (1 byte, I know) -- but about 128x as flexible as "ok"/"die" > (i.e. any non-zero value triggers the behavior > now, but before, it didn't). That's fine, even clever, but fundamentally incompatible with the idea that 0 means success and everything else means failure. > My simplistic view was that -e was there to auto-exit if an external > command failed because they are "out of your control". That's an incomplete view. -- ``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/