Re: proposed BASH_SOURCE_PATH

[Martin D Kealey]

On Thu, 16 May 2024 at 03:03, Chet Ramey <chet.ramey@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