Re: enable builtin bugs in bash 5.2

[alex xmb ratchev]

On Tue, May 30, 2023, 22:55 alex xmb ratchev <fxmbsw7@gmail.com> wrote:

>
>
> On Tue, May 30, 2023, 22:47 Robert Elz <kre@munnari.oz.au> wrote:
>
>>     Date:        Tue, 30 May 2023 15:28:57 -0400
>>     From:        Chet Ramey <chet.ramey@case.edu>
>>     Message-ID:  <ad399376-280e-bcdd-1aff-740f1a6ea4de@case.edu>
>>
>>   | Hmmmm. That's not the only option. How about we load it if found but
>> mark
>>   | it as not enabled? It will still take `enable -d' to delete it.
>>
>> That wouldn't match the man page, and isn't really rational.
>>
>> The man page says:
>>
>>     The -f option means to load the new builtin command name from
>>     shared object filename, on systems that support dynamic loading.
>>
>> and
>>
>>     If no options are supplied and a name is not a shell builtin,
>>     enable will attempt to load name from a shared object named name,
>>     as if the command were ``enable -f name name .
>>
>> That's all it says about loading anything.   So to load something,
>> either -f needs to be used, or no options be given.
>>
>> Of -n:
>>
>>     If -n is used, each name is disabled; otherwise, names are enabled.
>>
>> which is fine, but says nothing about loading anything (but is an option,
>> so if -n is given, we are not in the "no options" case).   Nor does it
>> say what happens in that case if name isn't a builtin - so that could
>> either just be ignored (like unset does for vars not set) or be an
>> error, either would be OK.
>>
>> For the behaviour you're suggesting, I'd expect the usage to be
>>
>>         enable -fn name
>>
>> which should load name (if it can be found, of course) and disable
>> it (though I'm not sure why anyone would ever want to do that).
>>
>> kre
>>
>
> sorry .. cant read much text
> .. i be for newering , i understand mismatches
> but somewhen u gotta have them all
> .. peace
>
i mean also in a speedy manner

>