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

[Eli Schwartz]

On 6/30/23 12:53 PM, Chet Ramey wrote:
>> 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

I'm not certain how to respond to this other than "pretty sure that's
not how it works". We're not talking about dlopen here. Note also that
even with lazy binding (which is frequently disabled as a system-wide
security policy) the library is still opened, it just doesn't do
relocations until they are used.

But this feels like getting into the weeds -- it's not really related to
the goal of this conversation to debate exactly how efficient it is to
link to a library when that library's functionality is only used by some
parts of the program and never used on certain machines at all.


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


... instead, I would like to discuss the fact that it *is* possible.

If it doesn't make sense in the modern age, why not get rid of the
option and make readline mandatory?

If it makes sense to keep the option, then why does it *matter* what
people's justifications are for using the option? Writing robust
software means taking into account that it may be getting toggled.


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


"There will be consequences if you use this option".

What does this mean? Is it unsupported to do so?

Defaults are just defaults, not prescriptive instructions about what is
reasonable or sensible. Saying that something defaults to on, isn't a
good rationale for whether people toggling the default constitute an
unsupported state prone to not working.


> 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


This makes zero sense, sorry.

If I have to handle the case where compgen doesn't exist, and test that
"some other solution" exists and returns correct results, then at that
point I have no need of compgen and can just not bother using it at all.
It no longer provides added value.

The reason this is problematic is because there is a degree of
skepticism regarding whether such a fallback is correct at all.

But if I have a correct solution and am willing to support the hacks it
requires, then... mission accomplished?


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


This is splitting hairs.

"You need to do X."

"You need to not not do X."


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


This feels like a deeply, deeply, deeply unfair comparison.

I do not even understand why those options exist. It's like having an
option to compile GCC without support for for loops. What utility role
is such a bash supposed to perform?

Readline/progcomp support has a pretty clear scope. Bash is two things:
- an interactive console
- a valid script interpreter


and people using bash for a script interpreter have an easily understood
rationale for disabling ***library dependencies*** whose only effects
are to enable interactive functionality. The expectation is going to be,
that disabling this functionality will have no effect on use as a script
interpreter, and it's okay to disable use as an interactive console
because the user would, well, *interactively* notice problems which
happen as a result.

And that's kind of my whole question here to begin with. It's not clear
to me that it's a good idea to allow bash to disable part of the bash
scripting language at all. The "bash core" I want to assume is that
there is no core, only a complete language none of which is optional at
the compiled binary level.

If that's not going to happen, then the "bash core" I want to assume is
whatever is guaranteed to exist that cannot be turned off.


Either way, I believe that people disabling readline support don't
intrinsically expect that it will change the scripting language to
support fewer features. At least the progcomp help text says it enables
the complete builtin (but does not mention compgen). The readline option
help text doesn't mention that disabling it overrides progcomp to off,
so the connection between that and compgen disappearing is non-obvious.

My copy of the bash manpage doesn't suggest that these builtins are
optional, either.

...

I would appreciate guidance on what "the bash scripting language"
entails. If that entails "arrays are optional, compgen is optional,
process substitution is optional, do not assume that any of this stuff
is guaranteed to exist" then so be it.

My suggestion is that all these things are declared mandatory, and users
who wish to disable support for arrays are instructed that they should
not call the shell "bash" at all, but install it as some other binary
name. Maybe "tinysh".

It would be nice if the option to disable support for compgen was
separate from the option to disable support for readline, and the
"tinysh" naming recommendation only applied to the former, not the latter.


-- 
Eli Schwartz