Date: Fri, 17 May 2024 10:09:06 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <e44b4d4f-2ac5-495e-8681-992168e50...@case.edu>
| If you don't want `.' to search $PATH, turn off the `sourcepath' shell
| option.
That part I assumed was already taken care of (that is, would be) just
by use of the BASH_SOURCE_PATH variable. If it is set, PATH isn't used
(unless BASH_SOURCE_PATH=$PATH of course).
| the skipping $PWD has never been
| historical behavior and would be genuinely new,
Yes. For executables (the normal PATH search) it makes no sense,
nor does it for CDPATH, because of the way that both are typically
used, but for '.' (aka the old csh name "source") use without a full
path is very rare, and probably an accident (or one waiting to happen).
Being able to prevent it would be useful, I think.
| and we could make that part of the semantics of BASH_SOURCE_PATH.
That exactly was the suggestion.
| Sure.
| https://lists.gnu.org/archive/html/bug-bash/2024-05/msg00262.html
Yes, I saw that after I sent the previous reply - when messages get
addressed to me, they end up in my inbox, which I read & process
much more quickly than I ever get to mailing list mail, which goes
to its appropriate list mailbox instead. This one is the same!
| If you implement the functionality later, maybe we can talk about a
| different name that's acceptable to more implementors. But for now, it's
| bash-specific if it gets implemented at all.
Actually, I have a different idea, which might avoid the var name issue,
and be easier to get implemented elsewhere. It is kind of like the
earlier suggestion to use -i to mean something different, but not that.
Why not add a -p option to '.' to specify the path to search. That is
. -p "${BASH_SEARCH_PATH-${PATH}}" file
would work if someone decided to use the BASH_SOURCE_PATH var name to
store the path to use (defaulting to $PATH if that one isn't set).
Now of course, everyone is going to say "too difficult to do that all
the time", and they'd be right. So the one extra feature would be that
if used without the "file" arg (which is normally mandatory), as in
. -p path-like-value
it would set the default search path for later uses of the '.' command
(and if anyone feels that being able to read back what has been set, an
additional option could make that info appear on stdout, and source
nothing).
It is kind of attractive to make all of this just be an addition to the '.'
command, with no other externally visible intrusions elsewhere - that's
something I could probably support (still with the " . -p '' " semantic
of suppressing all "searches" of everything, full paths only, naturally).
The default value of this hidden internal path would be $PATH (using
PATH's value at the time of the '.' command in question).
| Sure, other shells shouldn't implement variable names that start with BASH_
| if they have different semantics than bash gives them, or if bash doesn't
| implement them, but there's nothing wrong with other shells adding BASH_
| variables that have the same semantics. Other than parochialism, of course.
The problem with doing that is that it means making sure that the "same
semantics" are accurately copied, even in a shell where there are other
differences, and then maintained to match changes that bash makes to how
the variable works. Not something I'm willing to undertake, and then
leave for my successors to deal with. Nor I suspect would most others.
| Sure, and then if bash were to implement SOURCEPATH, or something similar,
| then there would be objections similar to
|
| "it's barely tolerable to add more action-at-a-distance by introducing a
| new variable"
|
| but with the addition that it intrudes on the user's namespace.
Yes, I know ... and it was thinking on that after reading this message
originally that led to the idea above.
And just for fun, we could even propose adding the very first ever (since
Bourne created them) special parameter, likely "$." instead of a '.' command
option, to make the value of the '.' command's path known). That one isn't
likely to succeed (as a proposal), but I've always wanted for someone to
make a new special param, just because it's never been done -- I temporarily
had a "$+" which was the inverse of "$-" -- the option flags that are
disabled ... but that ended up not really having enough reason to exist,
especially as there's no agreement as to what counts as belonging in $-
anyway, just the options that "set" accepts, or also those that apply only
on the command line (like -c).
| > | I have high hopes for `GLOBSORT', though.
| > What does it do?
|
| Sorts the results of pathname expansion in different contexts using
| different criteria. It's a bash-5.3 feature.
Yes, Lawrence provided me with the info (I could have gone and found the
5.3 alpha man page source somewhere and read that, if I'd been sure it
would be there, but...). You can see my reaction to that on the list.
kre
