On Tue, May 30, 2023, 22:55 alex xmb ratchev <fxmb...@gmail.com> wrote:
> > > On Tue, May 30, 2023, 22:47 Robert Elz <k...@munnari.oz.au> wrote: > >> Date: Tue, 30 May 2023 15:28:57 -0400 >> From: Chet Ramey <chet.ra...@case.edu> >> Message-ID: <ad399376-280e-bcdd-1aff-740f1a6ea...@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 >