Since bash 5.2, enable mkdir is equivalent to enable -f mkdir mkdir.
But, if you use the -n flag, and mkdir is not a loaded builtin, it will
also be equivalent to enable -f mkdir mkdir (so the -n flag is
ignored), and the newly loaded foo will be enabled instead of disabled:
$ ./bash -c 'cd ./examples/loadables; enable -n mkdir; enable -a' |
> grep mkdir
enable mkdir
If you call enable -n mkdir again, mkdir will be disabled:
$ ./bash -c 'cd ./examples/loadables; enable -n mkdir; enable -n mkdir
> enable -a' | grep mkdir
enable -n mkdir
I think that this is not intended and that, if the -n flag is specified,
enable should only try to disable all the loadable builtins named as the
argument, and skip, with a warning message, arguments that are not
loaded builtins; instead of trying to load (as enabled) arguments, that
are not loaded builtins, from files in the current directory and
BASH_LOADABLES_PATH as it does now.
Another "bug" caused by the new behaviour of enable name is that
enable '' will be equivalent to enable -f '' '' that causes bash to
call dlopen() with "" as filename that, at least on GNU/Linux, seems to
have the same behaviour as NULL as filename, so dlopen() will use
current process's executable as file, and enable '' will try to load
the _struct symbol from the bash binary as a builtin, instead of
erroring:
./bash: line 1: enable: cannot find _struct in shared object : ./bash:
undefined symbol: _struct
./bash: line 1: enable: : not a shell builtin
The same thing happens when using enable -n '' since -n just is
ignored when the argument ('') is not a loaded builtin.
Also note that enable -f '' '' prints two error lines in bash 5.2,
while, in bash 5.1, it only prints one.
$ bash -c "enable -f '' ''"
bash: line 1: enable: cannot find _struct in shared object : bash: undefined
symbol: _struct
o/
emanuele6
