Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: =?UTF-8?B?T8SfdXo=?= 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: References: <87tuzzh34x.fsf@hobgoblin.ariadne.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" , "bug-bash@gnu.org" , "bash@packages.debian.org" To: Laurent Picquet 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <87tuzzh34x.fsf@hobgoblin.ariadne.com> Xref: csiph.com gnu.bash.bug:16326 31 May=C4=B1s 2020 Pazar tarihinde Laurent Picquet yaz= d=C4=B1: > 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=C4=9Fuz, wrote: > >> >> >> 30 May=C4=B1s 2020 Cumartesi tarihinde Laurent Picquet >> yazd=C4=B1: >> >>> Hello Dale, >>> >>> This is really interesting. >>> Should the 'local' command be the one able to detect that the assignmen= t >>> to >>> the variable had an non-zero exit code and return the non-zero exit cod= e? >>> >>> 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 assignme= nt >> encountered a problem, but that the expansion has failed, which has noth= ing >> to do with `local`. So there is no reason for `local` to return a non-ze= ro >> 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 >>> 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. I= f >>> > one of the expansions contained a command substitution, the ex= it >>> > status of the command is the exit status of the last command >>> > substitution performed. If there were no command substitution= s, >>> > the command exits with a status of zero. >>> > >>> > In one of your examples, a "local" command is generated using a comma= nd >>> > substitution, so the exit status is that of the local command. In th= e >>> > other, only an assignment is done, which is not a command, so the exi= t >>> > status is that of the last command substitution. >>> > >>> > Dale >>> > >>> >>> >>> -- >>> >>> >>> -- >>> >>> Laurent Picquet >>> >>> 16, Hunters Chase >>> >>> >>> South Godstone >>> >>> RH98HR >>> >>> England >>> >>> tel: 07882 356 104 >>> >> >> >> -- >> O=C4=9Fuz >> >> --=20 O=C4=9Fuz