Path: csiph.com!au2pb.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.ripco.com!news.glorb.com!usenet.stanford.edu!not-for-mail From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= Newsgroups: gnu.bash.bug Subject: Re: -e does not take effects in subshell Date: Fri, 21 Aug 2015 18:48:55 +0200 Lines: 49 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> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1440175754 12373 208.118.235.17 (21 Aug 2015 16:49:14 GMT) X-Complaints-To: action@cs.stanford.edu Cc: Greg Wooledge , "bug-bash@gnu.org" To: Linda Walsh , chet.ramey@case.edu Envelope-to: bug-bash@gnu.org In-Reply-To: <55D672E8.70608@tlinx.org> X-Mailer: Evolution 3.16.5 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 199.195.249.9 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:11413 On jue, 20-08-2015 a las 17:38 -0700, Linda Walsh wrote: > Functions are a collection of many commands. They are not a single, > simple statement. I remember using their return value in some cases. >=20 > 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=20 > as "ok"/"die" (i.e. any non-zero value triggers the behavior > now, but before, it didn't). >=20 > My simplistic view was that -e was there to auto-exit if an external > command failed because they are "out of your control". But if=20 > I write a function -- I design the behavior. Even if I designed in > a bug -- it's still "my code" that has the problem not some > -_e_xternal command If you design the function, you can put an exit 0 on them, so they never return a non-zero status. It is completely sensible that if "echo foo > /dev/full" fails, it behaves the same way no matter if it's /bin/echo or a builtin what is run by "echo". Note that Windows has a similar deviation between binaries and batch scripts. A .bat containing: foo bar will run foo.exe then bar.exe if there's an executable named foo.exe, but only foo.bat will be run if it happens to be a .bat script (ie. acts as if prefixed by exec(1) when it's a .bat). And you can't know beforehand (even worse, someone may have installed a .bat with the same name as a .exe in order to slightly augment it). Treating all of them consistently is the way to go. > ---- cf. perl's option "autodie" -- you can say you want the "open > builtin" to just die on errors, then for simple scripts you don't > have > to put extra code to handle each problem. I.e. -- it's not really=20 > something you want in production code, but I write far more throw > away quick and dirty scripts than production ones. =20 I would to like to have a way to automatically set -e all functions defined after that, but it's orthogonal to treating them as commands. >=20