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