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

[Sam James]

Chet Ramey <chet.ramey@case.edu> writes:

> On 6/29/23 11:16 PM, Eli Schwartz wrote:
>
>> 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".
>
> Maybe. I don't think it's that big a win.
>
>> 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.
>
> The dynamic loader has to know where the library is. If you don't call
> readline, it shouldn't ever have to actually map it into the process.

I think it still has to map it even with lazy binding, but I'm not
really worried about this point much.
>
>> (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.)
>
> Yes, but the question is whether or not that makes sense in the modern age,
> and whether there should be extra features to accommodate that decision.
>
>
>> 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.
>
> But this isn't right. You have to explicitly disable those configuration
> options -- they're on by default. You don't have to do anything to get
> readline support compiled into bash. You have to do things to disable it.
> If you take that extra configuration step to disable it, there are going
> to be consequences.
>

There's a few open questions here:
1. Is the inconsistency between functions and variables desirable here?
(i.e. functions being something we can handle via `declare`, but
variables needing `compgen`?)

2. Is something on-by-default enough of a signal that you should rely
on it being available? Can I suggest editing the configure help text
to make clear you strongly recommend it be enabled?

3. On the Gentoo side, why do we need to turn it off while bootstrapping
prefix? I strongly suspect we can at least fall back to the bundled bash
readline for bootstrapping purposes and this isn't a problem in reality
anymore, but I'll check.


>> 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?
>
> You can always check whether compgen is available and fall back to some
> other solution if it's not.
>
> compgen -v >/dev/null 2>&1 && have_compgen=1
>
>> 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"?
>
> No. You need to say that users should make sure they haven't disabled
> them when compiling their bash binary.
>

Then the configure help text should reflect that. But needing compgen
for this is still odd, in any case. Or feels it to me.

>> Should I eschew compgen and rely on eval-using hacks like the one Kerin
>> described?
>
> It's your call, of course. You just have to decide whether or not it's
> worth the effort to accommodate non-default option choices. What about
> aliases? Arrays? Brace expansion? Process substitution? Extglobs? All of
> those can be compiled out. What's the `bash core' you're going to assume?

Only one of these requires an external (modulo the bundled copy) library.