On Sat, May 18, 2024 at 3:23 PM Matheus Afonso Martins Moreira < math...@matheusmoreira.com> wrote:
> > > That would cause shell scripts to see it and exhibit a change in > behavior. > > Only if the -i option is not implemented. > If it is, there will be zero change in behavior > whether BASH_SOURCE_PATH is set or not. > Only if the script explicitly passes -i to source > will the behavior change. > I am xing fingers the consensus, if any of theses takes off, is to have the -i implemented (not omitted) along with a protection against alias source='source -i' I really depend on actual 'source' behavior, and can't update my packages (distributed since long). I don't plan to use BASH_SOURCE_PATH, so if one, distro, sysadmin, and ultimatly the user fiddle with BASH_SOURCE_PATH in the ENV (*rc files), changing the good'ol 'source' behavior, it would be a serious regression to me. So to me BASH_SOURCE_PATH enablement must be guarded by a never used yet option to 'source or dot' (here -i apparently) and an enforcement that no alias source='source -i' could ever be possible. All this is because one writing a 'main' script (#!/bin/bash), sourcing a package of mine through my package management system, expecting the current source behavior, and later add the loading of a 'libraries' from a friend (terminal color jazz) that in turn start to mess around with alias source='source -i' and BASH_SOURCE_PATH cold start to break my way of finding my packages. An alternative to this would be BASH_SOURCE_PATH="" don't do nothing with 'source', and allow the 'libraries' designer to do typeset -r BASH_SOURCE_PATH="" in the early step of the main script, so nobody will ever be able to do anything clever with BASH_SOURCE_PATH, or could add import from incompatible packages system. But even this idea is a pb to me because it would require a change an my side that is not really doable. Well in short don't break the old source semantic.
