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

Groups > gnu.bash.bug > #16326

Re: local failure

Show all headers | 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