On 5/16/24 11:36 PM, Robert Elz wrote:
Date: Thu, 16 May 2024 11:36:50 -0400 From: Chet Ramey <chet.ra...@case.edu> Message-ID: <613852f3-c9ef-43d8-821b-37be3d9e9...@case.edu>| You can already do this; there's no reason to add these semantics to a | variable setting. How? What I'm looking for is a way to catch accidental ". foo" type things (by causing them to fail, regardless of whether "./foo" (or some other random "foo") exists and contains valid sh code).
If you don't want `.' to search $PATH, turn off the `sourcepath' shell option. If you want to temporarily change it, toggle the option. That addresses the path searching issue; the skipping $PWD has never been historical behavior and would be genuinely new, and we could make that part of the semantics of BASH_SOURCE_PATH.
| > can exclude ./anything or ../anything from that if you prefer - ie:
| Those are not relative paths.
Of course they are, that "." (or "..") is relative to something, it
isn't referring to a fixed location in the file system tree (like "/foo"
would be).
You might choose to categorise them differently, that's fine, but
there's no semantic difference between "./foo" and "dir/foo" - both
look for some directory ("." or "dir") within some other directory,
which usually depends upon other factors (such as the current PWD).
Sure. https://lists.gnu.org/archive/html/bug-bash/2024-05/msg00262.html
| > exclude anything which would skip the PATH-like search anyway) would | > simply fail (not just return itself and be attempted relative to ".") | | Is this really valuable? I think so, and given that any other reasonable interpretation I can think of has alternative (just as simple) mechanisms to accomplish, it seems to me like it would be reasonable. If you want BASH_SOURCE_PATH=. then that's exactly that easy to accomplish. You can make the default when BASH_SOURCE_PATH is unset be whatever you like (like using PATH, or doing something entirely different), but having it set to "" seems like it ought mean "no path search".
That's what it means now (or would mean now), since interpreting "" as equivalent to "." is standard for PATH-like variables. But that's not what you want. It's easy to say that if you use BASH_SOURCE_PATH, `source' doesn't fall back to $PWD if something is not found in the path. In that case, it's up to the user to put "." (or equivalent) into BASH_SOURCE_PATH, or not.
| Maybe. We'll have to see. People will object no matter what the name is. It isn't a matter of objecting, I have no objection to BASH_SEARCH_PATH, but I'm never going to implement that var (just as I wouldn't implementBASH_VERSION or any of the other BASH_XXX vars that exist).
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.
and other shells than bash, never).
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.
It's hard to get consensus on something when it isn't possible to even agree on a name all can use
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. But there's nothing set in stone, since nothing's been implemented yet.
| I have high hopes for `GLOBSORT', though. That is at least a plausible name - never heard of it, and my bash man page (still at 5.2, I have a 5.3-a1 binary, but haven't installed its man page anywhere) doesn't mention it. What does it do?
Sorts the results of pathname expansion in different contexts using
different criteria. It's a bash-5.3 feature.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
