Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Laurent Picquet <lpicquet@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: local failure
Date: Sat, 30 May 2020 15:33:20 +0100
Lines: 51
Approved: bug-bash@gnu.org
Message-ID: <mailman.704.1590849215.2541.bug-bash@gnu.org>
References: <CAH+roKWmQLjDGf_UpDabq6AHN+CVF_bKd1uyO2d8EadXzJ72MA@mail.gmail.com> <87tuzzh34x.fsf@hobgoblin.ariadne.com> <CAH+roKX_x6t3sKkbkgc-xa7XXSMpFCUJr6p4kVzXUB=E_pbw8A@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: bug-bash@gnu.org, bash@packages.debian.org
To: "Dale R. Worley" <worley@alum.mit.edu>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <87tuzzh34x.fsf@hobgoblin.ariadne.com>
Received-SPF: pass client-ip=2a00:1450:4864:20::141; envelope-from=lpicquet@gmail.com; helo=mail-lf1-x141.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN
X-Spam_action: no action
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID: <CAH+roKX_x6t3sKkbkgc-xa7XXSMpFCUJr6p4kVzXUB=E_pbw8A@mail.gmail.com>
X-Mailman-Original-References: <CAH+roKWmQLjDGf_UpDabq6AHN+CVF_bKd1uyO2d8EadXzJ72MA@mail.gmail.com> <87tuzzh34x.fsf@hobgoblin.ariadne.com>
Xref: csiph.com gnu.bash.bug:16322

Hello Dale,

This is really interesting.
Should the 'local' command be the one able to detect that the assignment to
the variable had an non-zero exit code and return the non-zero exit code?

as a developer, it is counter-intuitive that the 'local' command tells us
everything is ok when it wasn't. If feel it should know that the assignment
encountered a problem and should report it

The return status is zero unless local is used outside a function, an
invalid name is supplied, or name is a readonly variable.



On Fri, 29 May 2020 at 03:43, Dale R. Worley <worley@alum.mit.edu> wrote:

> It's a subtle point.  See this paragraph in the bash manual page:
>
>        If there is a command name left after expansion, execution
>        proceeds as described below.  Otherwise, the command exits.  If
>        one of the expansions contained a command substitution, the exit
>        status of the command is the exit status of the last command
>        substitution performed.  If there were no command substitutions,
>        the command exits with a status of zero.
>
> In one of your examples, a "local" command is generated using a command
> substitution, so the exit status is that of the local command.  In the
> other, only an assignment is done, which is not a command, so the exit
> status is that of the last command substitution.
>
> Dale
>


-- 


-- 

Laurent Picquet

16, Hunters Chase

South Godstone

RH98HR

England

tel: 07882 356 104