Date: Tue, 14 May 2024 15:51:10 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <c88fb0b0-4fd8-437d-bc8f-ab7f5335b...@case.edu>
| What do folks think about forcing an option to enable using
| BASH_SOURCE_PATH? Should it be required? Is it necessary? (I personally
| think it is not.) We discussed this briefly last week but without any
| conclusion.
An option isn't needed. If this were to be added at all, the right way
would be to simply if not in posix mode, then use BASH_SOURCE_PATH (if it
is set (PATH otherwise), or perhaps set and not '' - though personally if
this were me adding it, which would be unlikely, but if I were to be
convinced to do that, I'd make it set to '' mean that only paths containing
a '/' would work for the '.' command) and:
just as in another message chet.ra...@case.edu said:
| I don't like bash providing a default for this when bash doesn't install any
| `libraries'. Maybe it would be better to let it be something the builder or
| distro defines.
I agree, but it should be expected to be defined in a profile type file
if it needs to be defined at all (a system wide one, or a user's personal one).
The default (as compiled without extra config) should be unset.
But I don't think any of this is needed at all. I agree with the OP
that having '.' use PATH is archaic, and fairly dumb. I avoid that
by simply always giving a full path to the '.' command, never a simple
name. If I want to search for what that path should be, given a list
of directories, and a file name, then I use a shell function to find the
full path from the list and name. But that's very rare.
Not building support for this into (any) shell means that the code to
make it work will work (or should, if written correctly) in all shells,
rather than only in one, making for much more portable scripts.
kre
ps: I particularly dislike all the changes that are "just to make the
code easier to understand" (and similar) - suggesting that kind of thing
is OK, but it is up to the maintainer to decide upon the code style, not
others. Mixing that kind of thing in with other (substantive) code changes
is totally the wrong thing to do - makes it harder to extract the actual
changes, if something ends up not working, it can be hard to be sure whether
it is because the change wasn't installed as intended, or was always broken.
