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 > >