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

[Chet Ramey]

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.

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

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

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

--
``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/