> Are you referring to BASH_SOUCE_PATH being a source-only extension to PATH?
I mean that I won't be able to commit a standard loadable script
location to my dotfiles repository if setting BASH_SOURCE_PATH
changes the behavior of source. It could break too many things.
> Yes it allows the location of library scripts to be specified
> separately but it's not really useful.
It's a quite useful as a simple way for users to reuse code.
It's not meant to be a full module manager but that doesn't
mean it's not useful.
> You also would prefer `source` to not touch anything in PATH if it's
> meant to look for libraries. Mixing it up is just programmatically
> unsound no matter how rare binaries in PATH might cause issues.
> Encapsulation of the feature is the right way to do it.
I agree. That's what the -i option does.
It keeps BASH_SOURCE_PATH completely encapsulated.
> I hate that I have to rely on an external binary just to load
> a script relative to the executable. Example:
>
> source "$(realpath -m "${BASH_SOURCE}/../../lib/script.bash")" || exit
>
> If the `source -i` feature won't load a script using the calling
> script as reference it's pointless and I'd rather see it not
> implemented.
Hey for what it's worth I think that's a really good idea.
I'd really like additional features like that for source.
For example, I could add a -r option which prevents
searching and assumes the script is relative to the
current one. I'd also like to ensure that each script
gets loaded exactly once no matter how many times
it's been sourced.
I can't even seem to convince folks
of the value of source -i though.
So I haven't implemented more
functionality than that.
> BASH_SOUCE_PATH on its own also adds little value.
The variable only solution is not ideal for me
but I'd still get a lot of use out of it.
