|
From: | Matheus Afonso Martins Moreira |
Subject: | Re: [PATCH v2 5/8] builtins/source: parse the -i option |
Date: | Mon, 20 May 2024 12:30:25 +0000 |
> 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.
[Prev in Thread] | Current Thread | [Next in Thread] |