Honestly, I share the same feeling as the others about the name `library'. The use of the ``library'' feels something wrong in this context.
I still think the variable name should be BASH_SOURCE_PATH. I've suggested `-l' as an *example*, but that's just because I couldn't come up with another letter. It could probably be `-p' following the similar option of `command -p'. The reasons that using "library" in this context feels strange are as follows: * The suggested feature just changes how the script file would be searched. This doesn't define what would be the library in Bash and what would not. The suggested feature can be used to load a library, but the reverse is not true; a library doesn't need to be sourced through the suggested feature. Even if a script file that contains a set of utilities is sourced with an absolute/relative path with a slash, I'd still call it a library. Even if it is found in PATH, I'd still call it a library. Even if it is found in the current working directory, I'd still call it a library. The suggested command-line flag forces the search to be in BASH_LIBRARIES_PATH and disables the search of libraries in PATH and the current working directory. You seem to try to justify the naming by explaining how the script files loaded by the suggested feature can be considered libraries, but to justify the naming you would need to explain also how the script files with utilities located in PATH or the current working directory are NOT considered libraries. If you would try that, I will contest against it. * We haven't been using the term `library' in the Bash codebase to mean the general scripts that contain a set of functions and are intended to be sourced. These have been just called script files without a specific name. When we introduce a new term, I'd expect a clear difference from the existing one. If the new mechanism is incompatible with the conventional script files, it would suffice as a difference. Or if the suggested feature would introduce new mechanisms dedicated to libraries (such as namespacing, dependency resolution, etc.) and those mechanisms are not going to be provided/available with the conventional `source' builtin, it would also suffice as a difference. As far as the new term means essentially a similar thing as existing script files, I don't see a reason to introduce a new term. * I feel not every script file that is intended to be sourced and usefully placed in BASH_LIBRARIES_PATH would be actually a library. It might define aliases and shell functions that the user can interactively call from the command line. It can also be an initialization code for the environment. It can also be just personal configurations. For example, would you call a single line file « eval "$(starship init bash)" » a library? Maybe you call it a library, but I wouldn't.
