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