bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chet Ramey
Subject: Re: Enable compgen even when programmable completions are not available?
Date: Fri, 30 Jun 2023 12:04:51 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]