Re: enable builtin bugs in bash 5.2

[alex xmb ratchev]

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

>