On Fri, Jun 30, 2023, 05:16 Eli Schwartz <eschwart...@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 > >
