On Sat, May 18, 2024 at 9:18 AM Martin D Kealey <mar...@kurahaupo.gen.nz> wrote: > On Thu, 16 May 2024 at 22:50, konsolebox <konsole...@gmail.com> wrote: >> >> On Thu, May 16, 2024 at 4:59 PM Martin D Kealey <mar...@kurahaupo.gen.nz> >> wrote: >> > 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. > > > Ok, that seems more reasonable, and seemingly parallels the supposed (*) > special-case behaviour of './' elsewhere. > >> > * 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. > > > Strongly agreed; I over-simplified my description. > >> `cmd` searches for the binary in PATH, `./cmd` doesn't. >> `source script` searches for the script in PATH. `source ./script` doesn't. > > > Yes I get that, but that's because ./script is a particular case of > subdir/script, and in POSIX subdir/script isn't searched for. (Supposedly > that behaviour is different when not in POSIX mode, but I couldn't confirm > that experimentally.) > >> 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? > > > To be clear, I was suggesting that "modulegroup/module.bash" should search > BASH_SOURCE_PATH; my fairly weak objection was to treating "./module.bash" > differently based on its textual form, but it's not the hill I want to die > on. If there's precedent elsewhere then I withdraw that objection. > > I wonder whether 'source -i' should ignore POSIX mode and behave as if it's > always "on"? > >> 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. > > > Put that way, it does sound a bit odd. > >> 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. > > > Hmm, I can see cases for both relative to $0 and relative to whichever file > contains the "source" command. > Is there a consensus on this?
I don't know. I didn't get a direct reply on this besides yours yet and I haven't thoroughly read the other thread. I just think it's the most sensible way to do it if ever default values and relative paths in BASH_SOURCE_PATH become supported. I also now think it's better to not support them at all since the main script itself is not a reliable reference. Relying on PWD makes it worse as well. Scripts less likely changing directories while calling `source -i` is not a valid reason to use it. `source -i` has to work consistently through and through in all cases. Please make sure you reply to bug-bash as well and not just to me. -- konsolebox
