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

[Kerin Millar]

On Thu, 29 Jun 2023 16:39:52 -0400
Chet Ramey <chet.ramey@case.edu> 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?

This is discussed in the referenced bug.

To begin with, readline is disabled during gentoo's bootstrapping stage. I'm 
not one of its release engineers, but I presume that there is a cromulent 
reason for doing so. Sam might be able to chime in on this. Meanwhile, portage 
tries to run "compgen -A function" when the time comes to save the "ebuild 
environment", which is always stashed in the "VDB" for an installed package 
(under /var/db/pkg). Naturally, these two things do not go well together. As 
such, the bug was filed with the intent of eliminating this (sole) use of 
compgen.

Now for my part in this. Without going into the details of portage's internals, 
some of the code concerning the processing of the ebuild environment is ... 
well, let me just put it politely by saying that it is far from ideal. I have 
been working on cleaning much of this up. Consequently, I have come to rely 
upon compgen quite heavily, duly compelling me to pose the same question: what 
is the reason for disabling readline support in the first place? In fact, not 
only is it unavailable during bootstrapping but users do also have the option 
to disable it. Admittedly, they never do in practice; it's an option that is 
made deliberately difficult to take advantage of. In any case, comments #7 and 
#8 were the catalyst for bringing the matter up here on the list, if you're 
interested.

As it happens, I have submitted a patch that replaces the use of "compgen -A 
function" with a "declare -F" parser, which is all well and good. The thing is 
that portage also has a legitimate stake in needing to enumerate all variable 
names. To that end, I had been using "compgen -A variable" in my fork. The 
implication of the bug is that I must refrain from using it, at which point the 
prospect of parsing "declare -p" is a tremendously unappealing one, to say the 
least.

Ultimately, depending on whether you entertain any of this or not, the outcome 
will be that I rely upon my eval-using hack - which I had thought of by comment 
#10 - in all perpetuity or look forward to a cleaner way of going about it that 
doesn't necessarily depend upon compgen being available. One possibility would 
be to extend declare in such a manner that it is able to print only variable 
names, just as declare -F prints only function names. Another might be to 
extend the "${!prefix*}" and "${!prefix@}" syntax in such a way that it is 
possible to match any name. To be clear, I am not as concerned with the matter 
as I was at the time that the bug was initially filed but would still welcome 
any potential improvement, if it is at all feasible.

-- 
Kerin Millar