Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Robert Elz Newsgroups: gnu.bash.bug Subject: Re: bash errexit shell option does not work in some cases. Date: Mon, 01 Jun 2020 17:28:20 +0700 Lines: 40 Approved: bug-bash@gnu.org Message-ID: References: <5a7df0ba-3ad1-1f35-1107-09fdd5950359@archlinux.org> <3f403934d6b5d23ca58afc5146416c7@cweb006.nm.nfra.io> <1704.1591007300@jinx.noi.kre.to> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1591416798 14510 209.51.188.17 (6 Jun 2020 04:13:18 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: Eli Schwartz Envelope-to: bug-bash@gnu.org In-Reply-To: <5a7df0ba-3ad1-1f35-1107-09fdd5950359@archlinux.org> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:3c8:9009:181::2 (deferred) Received-SPF: permerror client-ip=2001:3c8:9009:181::2; envelope-from=kre@munnari.OZ.AU; helo=munnari.OZ.AU X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 3 X-Spam_score: 0.3 X-Spam_bar: / X-Spam_report: (0.3 / 5.0 requ) BAYES_05=-0.5, RDNS_NONE=0.793, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <1704.1591007300@jinx.noi.kre.to> X-Mailman-Original-References: <5a7df0ba-3ad1-1f35-1107-09fdd5950359@archlinux.org> <3f403934d6b5d23ca58afc5146416c7@cweb006.nm.nfra.io> Xref: csiph.com gnu.bash.bug:16363 Date: Sun, 31 May 2020 22:46:48 -0400 From: Eli Schwartz Message-ID: <5a7df0ba-3ad1-1f35-1107-09fdd5950359@archlinux.org> While I generally agree with ... | Don't use errexit but not really with: | it does not mean what you think it does. (it does mean what I think it means ...) in this case: | You're merely the latest person to discover that this applies to you: | http://mywiki.wooledge.org/BashFAQ/105 doesn't really apply - the cases reported are simply bugs in bash, a shell implementing -e correctly should exit as it was expected to. This all results from earlier posix specs where -e and simple commands were linked - the wording has been improved (still short of perfect) and simple commands are no longer relevant (other than that exit status generally originates with the result from a simple command). I would note that the "echo end..." after the earlier echo that prints the exit status is poinltless - the echo printing the exit status is all that is needed, that one exits with status 0, so the following command is obviously going to run - if the shell were working properly, the first echo (and anything following) would never be encountered. All that said, back to the original advice, unless you really know what you're doing, and really understand the examples in Greg's FAQ page, then you almost certainly shouldn't be using -e. kre