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 c...@case.edu http://tiswww.cwru.edu/~chet/
