> If you don't set BASH_SOURCE_PATH (from the user's perspective; > I'm not sure what I think about a loaded `library' changing the global > user settings by setting it), you get the historical behavior.
It's also important to consider the opposite situation: distributions and/or users setting BASH_SOURCE_PATH globally which then results in existing scripts _not_ getting the historical behavior which matches what their authors expected at the time. In order to preserve that behavior, users would have to very carefully manage the scope of their BASH_SOURCE_PATH variable. Maybe they'll resort to wrapping the source builtin invocation in a function with a local BASH_SOURCE_PATH. It'd be just like the pure bash solution for safely overriding PATH for source that many suggested on this list. I think users should never have any need for such a function, source should be enough. In the worst case users would resort to assigning it before every source command to avoid the risk of breaking existing scripts. It'd turn into one of the many shell features that shellcheck tells users to be careful about, and the fix would be to add the variable assignment to every source command. In that case, it'd work just like the -i option since it would have to be included in every invocation, but it'd be more verbose and less ergonomic. Even if users resorted to that, the environment variables are passed down to new processes, new subshells and new in-shell execution contexts. All bash scripts sourced while BASH_SOURCE_PATH was defined will have different behavior, so users of BASH_SOURCE_PATH won't be able to safely source existing scripts which themselves use source. It's as if invoking source -i caused the -i option to be passed to the source builtin of every subshell in the process tree instead of just that one invocation. It ends up recreating the same problem we're trying to fix. We're adding a new variable to avoid the need to touch PATH but at the same time we're forcing users to avoid touching BASH_SOURCE_PATH. It also creates two mutually exclusive categories of scripts: those written for PATH and those written for BASH_SOURCE_PATH. They can't call into each other. The advantage of the -i option is that users can set BASH_SOURCE_PATH in their rc files or environment and nothing happens by default. Only new code which explicitly passes the -i option to the source builtin get to use this new behavior. It also remains compatible with existing scripts since the option is not passed down the process tree like the environment variables. Only that invocation gets the new behavior, other code still has to opt into it by passing the -i option. It also has the advantage of being much shorter to type which makes it very ergonomic for interactive shell users. -- Matheus
