2024年5月3日(金) 9:56 Matheus Afonso Martins Moreira <matheus.a.m.more...@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.more...@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).
