> You can prepare a separate directory for the script files to source
> and put the directory name at the beginning of PATH, e.g.,
> PATH=~/.config/bash/functions:$PATH.
This is suboptimal. In case the library script cannot found
in the intended directories, it will needlessly search every
other entry in PATH for it, despite the fact they will contain
only unsuitable executables and programs.
It also raises the possibility of false positives:
finding a different executable with the same name
and sourcing it, causing hard to debug problems.
My main objective is to create an entirely separate
search space for the bash libraries so that importing
can be counted on to be both efficient and safe.
Overloading the existing source builtin would also
accomplish that goal if PATH is not searched.
> you seem to assume the script files to source have the executable
> permissions, but you can/should put the files without adding the
> executable permission to avoid the confusion you mention.
That's true and a good point. It was my intention to
reduce the number of candidate directory entries as
much as possible. Would you say that it would never
be appropriate for a shell script library to be executable?
It might be useful to reverse that condition: make it so
only non-executable files can be imported instead.
What do you think?
> In addition, BASH_LIBRARY_PATH (or BASH_SOURCE_PATH) for the source
> builtin seems already in the ``list'' [1]. The new builtin would
> become unnecessary If it is implemented.
I'm very happy that it was added to the list of planned features.
Still, it was my intention to contribute the patches from the start.
If nothing comes of this, at least I've gained experience with
the bash code base, facillitating future contributions.
> We need to be careful in adding a new builtin name since existing
> users might already have an executable file "import", which would be
> hidden by the suggested new builtin. The name "import" is not listed
> in POSIX XCU 2.9.1 (1b), the list of command names that a shell
> implementation might process specially.
That's a very good point, I was not aware of that!
What if instead of a new builtin, we added options to source?
This:
import some-file
Could become this:
source -i some-file
source --import some-file
More verbose, but it would avoid the aforementioned issue.
When given the import option, source could behave as import.
> If this builtin would be included, I think this should be a loadable
> builtin that the user can enable as an option.
That's a good idea. When I studied the source code,
there were comments saying the builtins could be
turned off and even programatically detected
via the enable builtin. I made use of those
facilities so the import builtin should already
have these properties. I'm not sure if it's a
dynamically loadable module but it probably
could be.
> it should better be a script file in /examples/functions
In this case, would every script automatically
have access to the import function?
> I've checked the discussion in help-bash [2]. The above arguments seem
> to be already mentioned in the original discussion. You say you've
> included everyone's thoughts [3,4], but no one seems to have
> recommended adding a new builtin.
That's true. I took initiative and implemented an alternative solution
when objections to overloading the behavior of the existing source
builtin began to surface. I thought they were really good points,
so I approached the problem from a different angle.
Different concerns regarding this proposal also surfaced,
such as the standardization issue. They also have merit
and I will try to address them as well. For example,
I think the "add --import option to source" is starting
to emerge as a promising solution.
> so simple that I doubt it should be defined as a separate library
> file. It can be copied directly into the script file.
It could, but that opens the door to variation.
I think a simple, standard and predictable
include/import/source mechanism is of
paramount importance if a true library
ecosystem is to form around it.
Variation in such critical infrastructure
has led to enormous pain for developers
working in other languages which have
multiple semi-compatible or incompatible
module systems for example. They end up
having to support several systems.
> Even if it wouldvbe defined in a library script file,
> you need to anyway specify a path
> in BASH_IMPORT_PATH to use that function.
With sensible defaults, this problem is mitigated
if not completely eliminated.
It's important that it be flexible and user overridable,
but most people will be well served by well chosen
default paths such as:
~/.local/usr/lib/bash:/usr/lib/bash
This allows libraries to be packaged by Linux distributions
and installed system wide, and also allows users to install
bash code inside their home directories and immediately
become productive.
Thanks for the feedback,
Matheus
