On Thu, 16 May 2024 at 03:03, Chet Ramey <chet.ra...@case.edu> wrote:
> On 5/14/24 2:08 AM, Martin D Kealey wrote: > > I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I > would > > like to suggest three tweaks to its semantics. > > > > A common pattern is to unpack a script with its associated library & > config > > files into a new directory, which then leaves a problem locating the > > library files whose paths are only known relative to $0 (or > > ${BASH_SOURCE[0]}). > > That assumes a flat directory structure for the script and its associated > files, correct? How common is that really? Or is it more common to have > something like the script in somewhere/bin, files to be sourced in > somewhere/lib, and so on? > On the contrary, I would expect a typical setting to be something like BASH_SOURCE_PATH=../lib:../config Or alternatively, that people will write: source -i ../lib/module.bash source -i ../config/theproject.conf making use of the implicit '.' when BASH_SOURCE_PATH is unset or empty. > > 1. I therefore propose that where a relative path appears in > > BASH_SOURCE_PATH, it should be taken as relative to the directory > > containing $0 (after resolving symlinks), rather than relative to $PWD. > > Is this pattern really common enough to break with existing behavior like > you propose? > It's something that people try to do often enough that there's a HOWTO for it Greg's Bash FAQ, and a bot auto-response in ircs:irc.libera.chat#bash. And sadly, people do indeed often make scripts that are brittle or outright broken because they assume $(dirname $0) == '.' Just search for how many shell scripts suggest using './name' to invoke them. To be fair, the commonest case is looking for a "configuration file", rather than a collection of modules But yes, unpacking any tarball or cloning any git repo will result in a directory tree grafted to a random point in the filesystem, and it'll stay that way if it doesn't have an explicit installation procedure (such as "make install"). You also suggested not having '-i' and just enabling the new behaviour when BASH_SOURCE_PATH is set. I strongly disagree with this for two reasons. (1) it's barely tolerable to add more action-at-a-distance by introducing a new variable; but adding *invisible* action at a distance is a language design antipattern. Having `-i` on the `source` command documents that new behaviour is expected. (2) We want it to fail with 'source: can't file "-i"' when run on a version of Bash that can't provide this suppression. -Martin