I support BASH_SOURCE_PATH as replacing the normal PATH search only for "."
and "source".
In addition I propose some new '~' expansions which will give concise
expression of dirname+realpath without penalizing code that does not need
it.
The primary intention is to allow the "standard preamble" to reduced to
simply
SOURCE_PATH=
or in more complex situations perhaps
SOURCE_PATH+=:˜./lib:˜./../lib
so that
. module.bash
will read "module.bash" from a location relative to the current file,
without regard for $PWD or $PATH.
The short preamble "SOURCE_PATH=" relies on a (proposed) rule that when
SOURCE_PATH contains an empty element, it is treated as equivalent to "˜.".
(It could be argued that an explicit syntax such as
SOURCE_PATH=${BASH_SOURCE[0]@R@D} would be more general, and I would favour
also implementing those modifiers, but it's also a well understood
engineering principle that we should make systems so that it's easier to do
the "best thing" or "right thing". Also unknown ˜ expansions will pass
through unchanged on any version of Bash that does not understand them,
whereas ${var@R@D} will provoke a syntax error.)
The new ˜ expansion forms are ~@[DIGITS] and ~.[DIGITS] (where [DIGITS]
denotes zero or more decimal digits). The ~@ form expands to a "partially
normalised form" of an selected path as explained below. The ~. form
expands to the dirname of the corresponding ~@ form.
I defined this "partially normalised form" as approximating what "realpath"
provides, but with weaker guarantees: the basename of the expansion is
guaranteed to be the final value after resolving symlinks, but the path
before that may be any path that is functional, especially if $PWD is
inaccessible. In particular it may not be an absolute path, or might start
with a prefix like /proc/1234/fd/99/.
With no digits, ~@ expands to a partially normalised path to the current
file, ${BASH_SOURCE[0]}.
When zero, ~@0 expands to a partially normalised $0.
Otherwise ~.NUMBER expands to a partially normalised form of
${BASH_SOURCE[NUMBER]}. (This might be omitted from the initial
implementation; we probably need more experience to see if it's actually
useful.)
-Martin
On Thu, 20 Jun 2024, 10:12 konsolebox, <konsole...@gmail.com> wrote:
> On Thu, Jun 20, 2024 at 4:05 AM Will Allan <billyz...@yahoo.com> wrote:
> > But, I still don’t like it. I have to start off each script with a slow
> command substitution (subshell) which introduces a variable that I don’t
> really want, but it’s too slow to do this repeatedly:
>
> I agree.
>
> > source -- "${BASH_SOURCE_PATH}/../lib/foo.sh"
>
> You misunderstood the use of BASH_SOURCE_PATH though. It's proposed
> to be an alternative to PATH which is only respected by source. I
> suggest another name. And that is BASH_SOURCE_REAL.
>
> Alternatively, have BASH_SOURCE always produce real physical paths
> either by default or through a shopt.
>
> Any additional feature that doesn't allow loading a script relative to
> the caller without external help is practically useless.
>
>
> --
> konsolebox
>
>
