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

[Ti Strga]

On Fri, Aug 16, 2024 at 3:26 PM Chet Ramey <chet.ramey@case.edu> wrote:
> This is on ubuntu 24 on an AWS VM.
>
> ubuntu@ip-172-29-1-101:~$ echo $BASH_LOADABLES_PATH

I'm using Ubuntu 22, also on an AWS VM.  There's no
BASH_LOADABLES_PATH set at all by default, looks like.


> ubuntu@ip-172-29-1-101:~$ ls /usr/lib/bash
> ls: cannot access '/usr/lib/bash': No such file or directory
[...]
> so it appears that none of the directories in the default Ubuntu value of
> BASH_LOADABLES_PATH actually exist. I don't know where they're installed,
> if anywhere, and I didn't bother to search beyond these.

For Ubuntu, at least, they're in a separate package "bash-builtins"
containing the sources and the compiled binaries.  The latter are
installed under /usr/lib/bash.  (This also explains why they don't
have BASH_LOADABLES_PATH set by default, I guess, although now I
wonder why they don't have the bash-builtins package also install one
of the /etc/profile.d fragments to do that.)


> I built bash-5.2.32 myself, in a private build directory, and this script
>
> BASH_LOADABLES_PATH=~/build/bash-5.2.32/examples/loadables:.
> enable cut

Interesting; that's exactly what fails over here:

$ echo $BASH_VERSION
5.1.16(1)-release
$ BASH_LOADABLES_PATH=/usr/lib/bash
$ enable cut
bash: enable: cut: not a shell builtin
$ enable -f /usr/lib/bash/cut cut
$ type cut
cut is a shell builtin

I wonder if this got changed between 5.1 and 5.2; I'll check on the
NEWS contents and the release notes when I get back to a computer with
the sources locally.