Re: [PATCH 0/4] Add import builtin

[Koichi Murase]

2024年5月3日(金) 9:56 Matheus Afonso Martins Moreira
<matheus.a.m.moreira@gmail.com>:
> The source builtin uses the PATH variable for resolving file names
> which means they would have to be placed alongside normal executables
> which could cause confusion.

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. As Lawrence has pointed out, 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. The source
builtin finds the file regardless of the executable permission. In
this way, it is clear to both the users and Bash that those files are
not executable.

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.

[1] https://lists.gnu.org/archive/html/help-bash/2024-04/msg00022.html

> This patch set introduces a new "import" builtin which behaves just like
> the source builtin but only looks up executables in the BASH_IMPORT_PATH
> variable.

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.

If this builtin would be included, I think this should be a loadable
builtin that the user can enable as an option. The loadable builtins
are included in /examples/loadables in the source tree of Bash. The
location of the loadable builtin files can be specified by
BASH_LOADABLES_PATH and loaded by the `enable' builtin.

However, as pointed out by Dale, what is done by this new feature can
just be implemented by a shell function. In this case, it is generally
recommended to implement it as a shell function. If you want to
include it in Bash, it should better be a script file in
/examples/functions (instead of a loadable module in
/examples/loadables). But considering the simplicity of the shell
function implementation by Dale and the fact that the source builtin
essentially covers the feature, I'm not sure if it's worth providing.

----

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.

[2] https://lists.gnu.org/archive/html/help-bash/2024-04/threads.html#00016
[3] https://lists.gnu.org/archive/html/help-bash/2024-05/msg00000.html
[4] https://lists.gnu.org/archive/html/help-bash/2024-05/msg00001.html

----

Reply to [4]

2024年5月3日(金) 9:56 Matheus Afonso Martins Moreira
<matheus.a.m.moreira@gmail.com>:
> Bash is powerful enough to do it with a function, no doubt about it.
> The thing is that approach begs the question of how to source that
> function which is also a reusable library function. This chicken and
> egg problem is why I believe a library facility is something that's
> better off as a native feature of the language.

The function « import() { PATH=$BASH_IMPORT_PATH source "$@"; } » is
so simple that I doubt it should be defined as a separate library
file. It can be copied directly into the script file. Even if it would
be defined in a library script file, you need to anyway specify a path
in BASH_IMPORT_PATH to use that function. I don't feel much difference
between specifying two paths (set BASH_IMPORT_PATH and source
/path/to/import.sh) and specifying only the former (set
BASH_IMPORT_PATH and source import.sh).