Re: proposed BASH_SOURCE_PATH

[konsolebox]

On Sat, May 18, 2024 at 9:18 AM Martin D Kealey <martin@kurahaupo.gen.nz> wrote:
> On Thu, 16 May 2024 at 22:50, konsolebox <konsolebox@gmail.com> wrote:
>>
>> On Thu, May 16, 2024 at 4:59 PM Martin D Kealey <martin@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