Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16326

Re: local failure

Path csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From Oğuz <oguzismailuysal@gmail.com>
Newsgroups gnu.bash.bug
Subject Re: local failure
Date Sun, 31 May 2020 18:22:31 +0300
Lines 121
Approved bug-bash@gnu.org
Message-ID <mailman.819.1590938556.2541.bug-bash@gnu.org> (permalink)
References <CAH+roKWmQLjDGf_UpDabq6AHN+CVF_bKd1uyO2d8EadXzJ72MA@mail.gmail.com> <87tuzzh34x.fsf@hobgoblin.ariadne.com> <CAH+roKX_x6t3sKkbkgc-xa7XXSMpFCUJr6p4kVzXUB=E_pbw8A@mail.gmail.com> <CAH7i3LoKQ_-QMMeMU-=5hcbqZPLfyu0i63f+KcMot+pQ6ruEtw@mail.gmail.com> <CAH+roKX-H_PjDu+UBPDiVUQjnd2eKK0E=L1r=0wg33X5paJpEg@mail.gmail.com> <CAH7i3LoDFRyu9+0p3QYj17CQgUczaW=4fh-aHSV45gB+xc0-Kw@mail.gmail.com>
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 1590938557 22903 209.51.188.17 (31 May 2020 15:22:37 GMT)
X-Complaints-To action@cs.stanford.edu
Cc "Dale R. Worley" <worley@alum.mit.edu>, "bug-bash@gnu.org" <bug-bash@gnu.org>, "bash@packages.debian.org" <bash@packages.debian.org>
To Laurent Picquet <lpicquet@gmail.com>
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VyV24MNqivwJzdrF/q7dVrbGLwPfWsFJYS1r2p0e+Ps=; b=oGosZ9CsbWAjbYw4BksMjv07BzcsUGSxryGY1ejdysP/VBDGYF/rymWKxyXEsFywPm Q7sfzwqjW0/lCJ9mJhJy1C6cfCi7nbuIf59dNwhge+hcDAuMUHjZHM1q9/V9c5YsQcwo 7kzxQ7hY+N4IUKhLV+ejEaju9FhVmsBhejbT7l/AWmbKevuTzGp4lJmx6/acvFYIzJbV 0nY1d14tSJhTk6BIRA8pPOZxV/+7uC9pMN7xhAPmTMZw3Z6DwLQujwRL5U+iXGucxda9 NDkhQlF7n4ZBu22AAXIHXgbJ3kl6V1GLjEt7cGYg1DXL4zH7BSFaQqt6DG0SA1KkHB+P SfpA==
X-Google-DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VyV24MNqivwJzdrF/q7dVrbGLwPfWsFJYS1r2p0e+Ps=; b=q/FGD44TgnZTozpBkNroC+vlgr/gqU1yB5Y4iZQbBVZDj5z8VFUJUkfO3+awKV9BBH Zn5qFNlOTKzTfcjDge2QieyZY6O5yPqZ9YKnO0FbT5puza3yuKUV8CMqgg6rNJu1zw9H fwM7DshQrV5ElhrQrT/3YB2Lz3Ya+1ZXt5loqPgXVPppcZVUOpC9X/drmnQFGNtsD5N/ n/iDpS3sE9DcQJ+Yw5HsAY0Pw/fDNR6ooY9HY93XW09qgBk+DNi6CJ4/KqwQxu5oE+6I WmOxd/oEfXF6k7TugoJUvy40g4/TwkNTIaNCbjlmbrUah2D5UVlYUQtQWoK703luZab8 C31Q==
X-Gm-Message-State AOAM533+/JGZ3aN07EPN1curJP/obwBqHBuI2oEFsJZrf1trCXhdf3lO k/0s+E6gd1xXEWYzUlJaFAjY/58N3HwSjQudWtw=
X-Google-Smtp-Source ABdhPJx3bzu6YPcyr2wfGoJm7SoFwHDG7aYGhfeC93fS4+FypJt2lWUSULhYhsPvwTzaz1Ek5xl3nNsaAeudYt+9NcQ=
X-Received by 2002:a37:76c1:: with SMTP id r184mr6762392qkc.414.1590938552206; Sun, 31 May 2020 08:22:32 -0700 (PDT)
In-Reply-To <CAH+roKX-H_PjDu+UBPDiVUQjnd2eKK0E=L1r=0wg33X5paJpEg@mail.gmail.com>
Received-SPF pass client-ip=2607:f8b0:4864:20::741; envelope-from=oguzismailuysal@gmail.com; helo=mail-qk1-x741.google.com
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 <CAH7i3LoDFRyu9+0p3QYj17CQgUczaW=4fh-aHSV45gB+xc0-Kw@mail.gmail.com>
X-Mailman-Original-References <CAH+roKWmQLjDGf_UpDabq6AHN+CVF_bKd1uyO2d8EadXzJ72MA@mail.gmail.com> <87tuzzh34x.fsf@hobgoblin.ariadne.com> <CAH+roKX_x6t3sKkbkgc-xa7XXSMpFCUJr6p4kVzXUB=E_pbw8A@mail.gmail.com> <CAH7i3LoKQ_-QMMeMU-=5hcbqZPLfyu0i63f+KcMot+pQ6ruEtw@mail.gmail.com> <CAH+roKX-H_PjDu+UBPDiVUQjnd2eKK0E=L1r=0wg33X5paJpEg@mail.gmail.com>
Xref csiph.com gnu.bash.bug:16326

Show key headers only | View raw


31 Mayıs 2020 Pazar tarihinde Laurent Picquet <lpicquet@gmail.com> yazdı:

> Ok, thanks for the clarification.
>
> This behaviour is not fully documented and I believe this should be
> addressed.
>
>
I think it is very well documented in the Simple Command Expansion section
of the manual (
https://www.gnu.org/software/bash/manual/html_node/Simple-Command-Expansion.html#Simple-Command-Expansion
).

I don't mind participating. Could you point me in the right direction to do
> that and raise a pull request?
>
>
I'm not a maintainer of the project. I guess you need to post a patch to
this list.


> Regards,
> Laurent
>
> On Sat, 30 May 2020, 16:32 Oğuz, <oguzismailuysal@gmail.com> wrote:
>
>>
>>
>> 30 Mayıs 2020 Cumartesi tarihinde Laurent Picquet <lpicquet@gmail.com>
>> yazdı:
>>
>>> 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
>>>
>>>
>> Everything is ok for `local` though; it takes a valid assignment
>> statement and successfully evaluates that. So it's not that the assignment
>> encountered a problem, but that the expansion has failed, which has nothing
>> to do with `local`. So there is no reason for `local` to return a non-zero
>> exit status in that case.
>>
>>
>>> 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
>>> <https://www.google.com/maps/search/16,+Hunters+Chase+%0D%0A+%0D%0ASouth+Godstone+%0D%0A+%0D%0ARH98HR+%0D%0A+%0D%0AEngland?entry=gmail&source=g>
>>>
>>> South Godstone
>>>
>>> RH98HR
>>>
>>> England
>>>
>>> tel: 07882 356 104
>>>
>>
>>
>> --
>> Oğuz
>>
>>

-- 
Oğuz

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: local failure Oğuz <oguzismailuysal@gmail.com> - 2020-05-31 18:22 +0300

csiph-web