From owner-freebsd-rc@freebsd.org Sat Jan 13 04:53:43 2018 Return-Path: Delivered-To: freebsd-rc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFD0FE738FE for ; Sat, 13 Jan 2018 04:53:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8B6773E89 for ; Sat, 13 Jan 2018 04:53:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id BCB651D9C2 for ; Sat, 13 Jan 2018 04:53:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w0D4rh95041579 for ; Sat, 13 Jan 2018 04:53:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w0D4rha8041578 for freebsd-rc@FreeBSD.org; Sat, 13 Jan 2018 04:53:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-rc@FreeBSD.org Subject: [Bug 190793] Some rc scripts return non zero status on success Date: Sat, 13 Jan 2018 04:53:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dteske@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-rc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 04:53:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D190793 Devin Teske changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dteske@FreeBSD.org --- Comment #6 from Devin Teske --- The attached patch upon review should NOT be applied. There is a better way that produces smaller diff while maintaining logical operands. The principal reason why the following can produce error status is because = the wrong logical operand is used with the wrong condition: [ -n "${foo}" ] && echo '.' We will call the following the "l-value" to the logical AND operator (&&): [ -n "${foo}" ] and we will call the following the "r-value" to '&&' operator: echo '.' The r-value is only evaluated when the l-value is true, and thus when the l-value returns false the logical AND result is likewise false (error statu= s). If you flip the conditional on its head and use the opposite logical operat= or (the OR operator in this case; "||"), then the l-value leaves a desirable success-status and desirably the r-value is not executed when the inverted condition is true. That sounds like a headache, but it's really simple. The above translates to: [ -z "${foo}" ] || echo '.' Here we say that if ${foo} expands to an empty string (unset or NULL), we d= on't execute the r-value. The net-effect is that "||" is almost always what you want when you are concerned about exit status. However, you have to be very careful in the rc.d world when you flip an "l-value && r-value" into an "! l-value || r-value" because of the possibil= ity that "set -e" may become neutered for a particular condition. The "set -e" directive in shell makes all errors fatal. The below will trig= ger a premature termination when "set -e" is in-effect (because the logical AND= is only successful if both l-value and r-value return success, a failure by ei= ther l-value or r-value will result in premature termination): [ -n "${foo}" ] && echo '.' Meanwhile, flipping this on it's head, despite appearing to not have an eff= ect code-wise, would negate a premature termination should "set -e" be in-effec= t: [ -z "${foo}" ] || echo '.' That's because the result of a logical OR between two commands is going to = be success if either the l-value or r-value returns successfully. Therefore, the way to address the reported problem of unassailable return status is not to blindly translate all logical AND operations into if-statements as the original patch would have done, nor do we blindly translate to logical OR operations, but really we need to look at each use-= case of logical AND and/or OR and determine: a. Should premature termination occur for either l-value or r-value in the event of a "set -e" b. Is the logical operation at the end of a function or script If neither of those things are true, leave it alone if it accommodates (a) above correctly as-intended. --=20 You are receiving this mail because: You are the assignee for the bug.=