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]}).
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.
As an interim step until that's implemented, please ignore any relative
entries in BASH_SOURCE_PATH, so that users who really want the cwd in
BASH_SOURCE_PATH get used to writing $PWD or /proc/self/cwd instead.
2. Search BASH_SOURCE_PATH when any relative path is given, not just a path
that lacks a '/', so that libraries can be organized into subdirectories.
3. To avoid accidentally loading a script rather than a library, while
searching BASH_SOURCE_PATH, ignore any files that have exec permission,
inverting the check normally made for executables in PATH. This would keep
executables and libraries functionally separate, even if they're commingled
in the same directories.
Yes I know that some folk think it's occasionally useful to have a single
file that operates as both, but (a) new features should default to the
"safest" mode of operation, (b) this isn't python and so that's pretty rare
in practice, and (c) there was at least two work-arounds should that
behaviour actually be desired: (i) use an absolute path, or (ii) use PATH
instead of BASH_SOURCE_PATH.
4. When using "source -i", if BASH_SOURCE_PATH is unset or empty, it's
taken as equivalent to '.', so that it's useful to write "source -i
../lib/foo.bash" in a script at "$X/bin/bar" to load "$X/lib/foo.bash".
-Martin
PS: in the longer term, perhaps PATH could have similar behaviour, but
gated by a shopt or compat check.
