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

[alex xmb ratchev]

On Fri, Jun 30, 2023, 05:16 Eli Schwartz <eschwartz93@gmail.com> wrote:

> On 6/29/23 4:39 PM, Chet Ramey 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?
>
>
> 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".
>
> 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.
>
> (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.)
>
> ...
>
> 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.
>
>
> 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?
>
> 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"?
> Should I eschew compgen and rely on eval-using hacks like the one Kerin
> described?
>

for no whatever i d need an eval
thinking u need eval implies wrong know how

-- 
> Eli Schwartz
>
>