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

[Chet Ramey]

On 6/29/23 6:05 PM, Kerin Millar wrote:
> 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.

Yes, the fact that gentoo uses a bash built without readline is there, but
no hint about why it's built that way.

> 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. 

Excellent use of `cromulent'.


> 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.

I skimmed the bug report. The option to disable readline during a bash
build is there because users asked for it long ago. I agree that it doesn't
make much sense in this day and age, and no one ever does it. The question
then becomes what advantage, in this modern era, is gained by compiling
bash without readline. The speed and space advantage does not accrue as
much as it once did, especially if you link readline against a system
shared library.

So before you propose work for me to do whose purpose is to protect
gentoo from the consequences of its decision, it would help to explore
the reasons for that decision. If those reasons have been lost to time,
maybe it's time to reevaluate.

> 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.

The output of declare -p is intended for the shell to parse -- so it can
be reused as input. That's always going to be its primary purpose.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/