On Sat, May 18, 2024, at 11:17 AM, Phi Debian wrote: > I am xing fingers the consensus, if any of theses takes off, > is to have [...] protection against alias source='source -i'
This seems out of scope, regardless of what happens with "-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. A reasonable concern, but distros, sysadmins, and users can already break your scripts in plenty of ways -- changing existing shell variables, setting shopts your scripts don't account for, etc. > 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. By this logic, ALL future shell variables ought to be gated similarly. No doubt some would embrace this, but it seems a bit heavy-handed. > 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. There's only so much you or bash itself can do to prevent users from breaking their own setups. Note that "source -i" precludes a sort of mirror situation. Someone who sourced scripts via PATH but wanted to switch to BASH_SOURCE_PATH would not be able to simply move the relevant directories from one variable to the other but would have to modify all sourcing scripts -- including third-party ones -- to use "source -i". If they declined to do this, then they'd have to keep using PATH for at least some scripts, possibly indefinitely. -- vq
