Behavior of "enable foo" doesn't seem to match bash(1) page.

[Ti Strga]

Yeah, I know, it's a bit obscure.

The man page documentation for 'enable' ends with:

enable [-a] [-dnps] [-f filename] [name ...]
     Enable and disable builtin shell commands.
     [...]
     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 .

(It's missing the closing quote marks, but that's not my question.)

Trying this on a recent Ubuntu installation:

     $ enable cut
     -bash: enable: cut: not a shell builtin

Even with explicitly setting BASH_LOADABLES_PATH appropriately, the
"if no options, assume -f" behavior doesn't seem to be kicking in.

Specifying "enable -f cut cut" works, of course, as long as
BASH_LOADABLES_PATH is set (whatever the defaults on this build were
apparently don't include the installation path), or completely
specifying "enable -f /usr/lib/bash/cut cut".

Cheers!
.

P.S. The little-known loadable 'cut'/'lcut' is very nearly perfect for
a task I'm looking at, barring some disappointment with cut's "-a
ARRAY" handling.  Probably I'll end up not using the builtin's looping
over the file (due to the array thing), and instead do something like
"enable -f /usr/lib/bash/cut lcut" and then either use
mapfile/readarray with lcut instead a -C callback, or the good ol'
"while read ... lcut... done < file".  Doing the field splitting
inside the shell rather than spawning a cut(1) process on each
iteration makes a surprising difference!