Re: Enable compgen even when programmable completions are not available?

[Eli Schwartz]

On 6/29/23 4:39 PM, Chet Ramey wrote:
> On 6/25/23 2:38 PM, Eli Schwartz wrote:
>> compgen is a useful builtin for inspecting information about the shell
>> context e.g. in scripts -- a good example of this is compgen -A function
>> or compgen -A variable.
>>
>> But it's not always available depending on how bash is built, which
>> results in people lacking confidence that it can / should be used in
>> scripts. See e.g. https://bugs.gentoo.org/909148
> 
> It's dependent on programmable completion and readline, which are features
> that are enabled by default. Who builds a version of bash with those turned
> off? What's the rationale for doing that?


I assume that, given the option exists in the configure script, there
are people who will want to use the option made available to them. One
reason might be because they are configuring it for a system that isn't
fussed about using bash for an interactive shell (either it is
administrated via non-interactive means, or simply because the preferred
interactive site shell is e.g. zsh). In such cases, a rationale that
readily comes to mind is "this user wanted a smaller, leaner bash binary
by disabling unimportant bits that they do not use".

And because this is conditional on readline, which is usually an
external library dependency (a global system policy decision), reducing
the number of shared libraries the dynamic loader has to deal with might
be especially interesting.

(This is all theorizing -- I quite like bash as an interactive shell and
have no intention of building systems with readline disabled. It is
nonetheless true that the topic came up because there are Gentoo users
who apparently decided to try to do so.)

...

The thing is, does it really matter? I think there's a larger issue
here, which I mentioned in the Gentoo bug report but probably makes
sense to copy/paste here:


> The problem with compgen is that it is only available for use when
> bash is configured with --enable-progcomp / --enable-readline, which
> feels like a powerful argument that script authors are not allowed to
> assume that it will exist, regardless of how useful it may be in
> non-programmable-completion contexts.
>
> Maybe the answer is to ask that it always be available as a builtin,
> even when the programmable completion system isn't enabled.


So: can I? Are my bash scripts valid scripts if they use compgen, or
should I be concerned that when I publish them for wide adoption, people
are going to report bugs to me that it is broken on their niche system
configuration which they are positive they have a good reason for?

Should I document in the project readme that in addition to needing a
certain minimum version of bash, "you also need to make sure that
programmable completions are enabled when compiling your bash binary"?
Should I eschew compgen and rely on eval-using hacks like the one Kerin
described?


-- 
Eli Schwartz