On Tue, May 14, 2024 at 2:09 PM Martin D Kealey <mar...@kurahaupo.gen.nz> wrote:
> 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.
This implies only the directory where the main script is located will
be used, correct?
Hopefully Bash already has a deterministic way of knowing the
directory the main script is located.
> 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.
I disagree with this. Paths beginning with ./ or ../ should be
considered explicit and not searched in BASH_SOURCE_PATH.
It should use the directory of the calling script as reference when
using -i or $PWD when not.
> 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.
This deviates from the known behavior of source and makes it less
intuitive. It can be useful but it should only be enabled with an
option.
I also don't like seeing my scripts highlighted in executable color in
ls's output when they don't have to be.
> 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".
I somewhat agree but ./ and ../ should be considered explicit so if
you want lib/foo.bash to load relative to BASH_SOURCE_PATH's ".", just
specify "lib/foo.bash".
--
konsolebox
On Tue, May 14, 2024 at 2:09 PM Martin D Kealey <mar...@kurahaupo.gen.nz> 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]}).
>
> 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.
--
konsolebox
