On Sun, 5 May 2024 at 11:50, Koichi Murase <myoga.mur...@gmail.com> wrote:
> > Ideally, they'll be using bash's native import under the hood!
>
> Yes, module managers still need to implement their own "import"
> command while using the proposed "import" primitive under the hood,
> and it's simply interchangeable with the source builtin we already
> have.
>
> * Module managers typically try to identify the file under more detailed
> rules [...] For these reasons, most module managers actually resolve the
> path by itself using their rules and specify *the absolute path* to the
> source builtin. As far as the absolute path is specified, there is no
> difference between the source builtin and the suggested `source -i' or
> `import'.
>
I wonder if it would be useful to add options to 'command':
* '-o' would report only the first command found (when more than one is
given) (or could be '-1');
* '-p' would skip builtins & functions, and fail silently if no file can
be found;
* '-x' would search for files that *lack* exec permission.
Then a module loader could simply be:
require() {
[[ ${__loaded_from[$1]} ]] && return
local rp
rp=$(
PATH=$LIB_PATH \
command -opvx "$1".bash "$1".sh "$1"
) &&
source "$rp" &&
__loaded_from[$1]=$rp
}
(Being a Perl monk, I like the distinction between 'require' that has
effect during run time, and 'use' that has effect during parsing. And
'import' is the process for binding names into namespaces, not the process
for loading files.)
-Martin
