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 21:51:54 +0700 Lines: 43 Approved: bug-bash@gnu.org Message-ID: References: <031b5b39-826a-6523-b03b-b839efe9eb63@archlinux.org> <5a7df0ba-3ad1-1f35-1107-09fdd5950359@archlinux.org> <3f403934d6b5d23ca58afc5146416c7@cweb006.nm.nfra.io> <1704.1591007300@jinx.noi.kre.to> <21042.1591023114@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 1591416714 14479 209.51.188.17 (6 Jun 2020 04:11:54 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: <031b5b39-826a-6523-b03b-b839efe9eb63@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: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, 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: <21042.1591023114@jinx.noi.kre.to> X-Mailman-Original-References: <031b5b39-826a-6523-b03b-b839efe9eb63@archlinux.org> <5a7df0ba-3ad1-1f35-1107-09fdd5950359@archlinux.org> <3f403934d6b5d23ca58afc5146416c7@cweb006.nm.nfra.io> <1704.1591007300@jinx.noi.kre.to> Xref: csiph.com gnu.bash.bug:16362 Date: Mon, 1 Jun 2020 09:16:17 -0400 From: Eli Schwartz Message-ID: <031b5b39-826a-6523-b03b-b839efe9eb63@archlinux.org> | I could not figure out whether the grammar allowed | or forbade this this result. It isn't the grammar, that would affect syntax, it is the semantics that matter here. What the current posix spec says is ... -e When this option is on, when any command fails (for any of the reasons listed in Section 2.8.1 or by returning an exit status greater than zero), [it exits, except for when ...] In the examples in question that failed, there was a redirection failure. of a compound command (grouping in the first, while in the 2nd). Redirection failures are amongst those listed in 2.8.1. None of the exceptions apply in the example cases, so the shell should have exited. | So this is actually that unbelievable of unbelievables, a script which | is broken because of set -e and it's actually because set -e has a bug? I don't know what the original script that led to the bug report was, nor if it makes sane use of -e (very few scripts do .. -e is best left for make to use) but the examples show bash "issues". bash (in non-posix mode) has some differences wrt when the shell exits, and doesn't - whether these ones fall into that category or not is not for me to say. kre ps: I know of one script that uses -e in a way that works, it consists of "set -e" and then a whole long list of simple commands, one after another, where if one fails, none of the following ones makes sense. I considered changing it, but as that would have just meant adding " || exit 1" at the end of every line .. literally every line .. or possibly making a huge "&&" and-or list (with only and) out of it all, it seemed like a case where "-e" was actually the right approach.