Re: proposed BASH_SOURCE_PATH

[Robert Elz]

    Date:        Wed, 15 May 2024 11:03:12 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <eac17217-b97d-4108-b971-5d4fd053f358@case.edu>

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

Personally, I don't think there is anything common here at all, most
scripts don't fetch bits from other places, everything simply goes in
the script, and the need for the '.' command at run time is avoided.

In general, I suspect that almost all use of '.' is for people writing
a bunch of scripts for personal use, which use a set of common functions
that that suit the needs of the person writing the script (so that
their common functions can be used without thought) - I have a bunch of
those in one file that I use all over the place, and another file that
has functions only useful in interactive shells, and one or two more
that have functions with more specialised uses.   Of course, I know
exactly where all those files are stored, and I just use ". /path/to/files"
(or more commonly ". "${FP}/..." to make it easier to modify if needed).
(and no, I don't use "FP", that's just an illustration.)

If I were ever to distribute any of these scripts, which isn't all that
likely, I'd simply find the '.' commands and include the functions that
are needed from the file, instead of the '.' command, and send away that
version (then there's no issue of the two different files diverging,
which could happen if a replacement for the script was sent, and that
some function in the included file had changes was forgotten).

If someone were to distribute a script, with script fragments in
different files (probably because there are actually several scripts
which share a set of functions) then it is very unlikely that they'd
rely upon the user (or package maker) following any set convention
for where things should be installed - everyone has their own way of
doing that, and puts things in different places.  For that, the sane
thing to do is have the script do

        . "%%SCRIPT_DIR%%/funcs1.sh"
        . "%%SCRIPT_DIR%%/fs-funcs/listings.sh"

(etc)

and provide a simple sed script which replaces %%SCRIPT_DIR%%
with the whatever (full) path name is that the user (or packager)
actually uses to place those files into.

All this "path searching" stuff is really unnecessary for the '.'
command, as no-one really needs to use it, except in fictional
environments that don't really exist.   That's why no-one really
even notices that the standard '.' command searches PATH for
simple filenames - because in practice, no-one ever does that.

That's why I really don't think any of this is particularly useful.

It's also I don't much care if a different path-like searching
method is defined, because I don't really think that almost anyone
would use that either.

kre