On Thu, May 16, 2024 at 4:59 PM Martin D Kealey <mar...@kurahaupo.gen.nz> wrote: > On Wed, 15 May 2024 at 16:33, konsolebox <konsole...@gmail.com> wrote: >> >> On Wed, May 15, 2024 at 7:16 AM Martin D Kealey <mar...@kurahaupo.gen.nz> >> wrote: >> >> > I'm concerned that doing both would introduce an entirely new dichotomy >> > for programmers to have to remember, so perhaps "skip path searching" >> > should be controlled by a separate switch, perhaps '-s'? >> >> No. `source` already searches PATH when ./ isn't provided. That's already >> intuitive. > > > We were discussing what happens with the proposed `source -i` which doesn't > look at PATH at all, with my additional proposed that it would only skip > searching BASH_SOURCE_PATH when the name doesn't start with '/', and moreover > that it would behave as if CWD=$(dirname $(realpath $0)) for the purpose of > resolving any relative path in BASH_SOURCE_PATH (including the implicit '.' > when it's empty). > > As I understood your counter-proposal, it would result in this: > * ./a and ./b/c/d would be treated as relative to $PWD
Not to $PWD but the calling script's directory. source as it is now already refers to $PWD. `source -i` will refer to the calling script's directory instead. > * a and b/c/d (any paths not starting with '/' or './') would remain as I > specified, and be treated as relative to $(dirname $(realpath $0)) Only if BASH_SOURCE_PATH is empty will $0 be used as reference because it becomes the default as you have suggested. But if it isn't, the paths specified in BASH_SOURCE_PATH will be used instead. > * /x/y/z would still be used as-is (no change) > If I've misunderstood your counterproposal, please explain further. > > In response to this, I contend that changing behaviour depending on a textual > prefix (that appears to be a normal path) seems unwise to me. At the very > least it should be marked in a way that indicates it's an expansion, such as > with '~' or '$'. Or simply provide another option to 'source' to control this. `cmd` searches for the binary in PATH, `./cmd` doesn't. `source script` searches for the script in PATH. `source ./script` doesn't. Why would you decide to change `source -i ./script` to also search for the script in BASH_SOURCE_PATH just because a bunch of newbies might misinterpret it? Are you implying to take the opportunity to "fix" the supposedly unintuitive behavior which is actually intuitive and make people need to remember that `source -i` differs from source and "cmd" when it comes to searching for scripts using relative paths? The obvious and ridiculous thoughts on this would be "it's already different anyway". I'm talking about the fundamental pattern on how a relative path is treated - by default. Not with any additional option. Even without considering source and "cmd"'s current behavior, it doesn't make sense to add an additional option just to make the shell know that you're referring to an explicit path relative to the current directory (or script) or not. > Lastly, I note that a very large number of scripts out on the internet only > work correctly when invoked with (cd /path && ./name) because they tacitly > assume that $(dirname $0) is '.', particularly when loading modules or > configuration files, and will break if invoked as /path/name from a different > directory. > > Changing the relative base from $PWD to $(dirname $0) goes a little way > towards improving that situation; we can simply tell novice programmers to > use 'source -i' instead of 'source', and it will just work; they don't need > to include six extra lines of arcane magic that they don't understand, and > they don't even need to set BASH_SOURCE_PATH (since empty or unset is > equivalent to '.', meaning $(dirname $(realpath $0))). > > There is precedent in the Linux kernel (and elsewhere) for relative paths NOT > being relative to $PWD; the openat(2) syscall allows the caller to provide a > filedescriptor connected to any directory, and indeed I suggest the > implementation should make use of this, rather than messing with path > concatenation. I'm not sure what to comment on those. Also just to make sure things are clear. I'm referring to "$0" here as the main script's path and not the calling script's path. BASH_SOURCE_PATH can be allowed to have a default value but it doesn't make sense if that "default value" changes meaning depending on the location of the script running. BASH_SOURCE_PATH's values are supposed to always refer to the same paths regardless if the values are relative or not otherwise that would be a broken behavior. Relative paths in BASH_SOURCE_PATHS if they become allowed should use the main script's directory as reference as well. -- konsolebox
