I think we can separate the discussion about the module system and the source builtin. What is the primary purpose or the reasoning behind the suggestion?
If the purpose is to introduce a standard module system in Bash, I'll have to be opposed to the change because I think the current suggestion for `source -i' wouldn't help satisfy that purpose at all. At least, it is immature or insufficient to be used as a module system. There are many things to consider, including the include guard I already mentioned, a central repository to avoid conflicts in the library names, etc. You also need to fight against existing module frameworks to convince them about introducing a mechanism that might beat them. If one has to implement a module system using a set of shell functions based on `source -i', the situation doesn't change from the current one with many module systems based on the source builtin. However, if the purpose is solely to solve the ambiguous search paths of the `source' builtin, I think a flag to the source builtin is a reasonable suggestion. Currently, the command `source <name>' might hit three different types of files: 1. a file in the current working directory 2. a script file (that is supposed to be sourced) in PATH 3. this is not intended, but an executable file that is not supposed to be sourced. To make the source builtin find type 1, one can use `source ./<name>'. However, there is no way to force type 2 without being affected by type 1 or 3 when the library is not found and/or there is a conflicting name. Then, we can prepare a separate variable BASH_IMPORT_PATH for the search paths for script files to source, and add a flag of the source builtin that forces searching only BASH_IMPORT_PATH. It's similar to `unset -v/-f/-n' where the command `unset <name>' can ambiguously remove a variable or a function, but `one can specify a type through -v/-f/-n. This is my personal preference for the name, but the current simple feature of restricting the search paths doesn't feel `import'. I'd think it can simply be BASH_SOURCE_PATH. The flag can also be something other than `-i' or `--import', like `source -l <name>' to mean the "library". 2024年5月4日(土) 3:00 Matheus Afonso Martins Moreira <math...@matheusmoreira.com>: > > No, those files need to be distributed by the Bash package of > > distributions, and the path needs to be properly set up. > > Then I don't think that would be the ideal solution. I feel we should ask the package maintainers to include those files. As for the loadable builtins, even though the recent versions of Bash install loadable builtins in $prefix/lib/bash when installed by « ./configure && make install », most package maintainers do not include them in the (main) package for some reason. As a result, even if Bash provides useful loadable builtins, the script writers cannot assume their existence, which is a problem. Currently, the files under /examples/functions are not installed even by « ./configure & make install », but I think useful shell functions can also be installed in e.g. $prefix/share/bash/functions, and also included in the packages of the distributions. > It's embarrassing but the truth is I was not even aware of these projects. Don't worry. You are here to ask the community about that. > My intention was simply to add a feature I wanted to bash. > I experienced difficulty with maintaining a growing collection > of personal scripts, had this idea, coded it up and sent patches. If it were the personal purposes, you could start it with a shell function implementation. There is no need to modify the upstream Bash for personal uses. It's not too late to ask for standardization when you need to share your framework with others. > > I also think the variation is actually needed because the assumed > > search paths are different for different libraries. We cannot simply > > merge all those implementations into a single command because each > > library wants to limit BASH_IMPORT_PATH to the locations they provide. > > Why is this required? > > > Then, it's identical to `PATH=<path> source'. I also think the > > variation is not a problem. The separation of the domain is useful. > > Please elaborate on this point. How is it useful? I assume the case where different module systems coexist. In particular, interactive frameworks and applications need to be loaded in a single instance of Bash even when they are not integrated with each other. The different module systems do not need to cooperate with each other but should be allowed to coexist in a session and work without interfering with each other. For example, when module X managed by system A requests another module Y, we want to find module Y provided by system A and exclude the modules provided by system B (even when no module is provided with the conflicting name Y in system B). The idea is the same as yours to separate the namespace of the executable files and the script files to source. > > If desired, the developer can choose one module framework > > and write their module for that module system. > > I think it's counter productive when developers have to choose > which module system to develop for. Yes, I agree with that. But everyone wants to sell their own module framework. The war begins. I think the war is a good thing to improve the language, but one needs to be prepared. > [...] I believe that there's exactly one exception > to the above rule: the module system of a programming language. > I think there should be exactly one library system, > and that it should be literally built into the language. I think a subtlety in shell languages is how to count `a' language. One may want to have a unique module system for POSIX scripts, and another may want to have a unique module system for Bash scripts. They inevitably conflict if they want to be the unique system. Some frameworks even try to implement ``a new shell language'' on top of POSIX (Modernish is this) or Bash (Bash Infinity is kind of this).
