Re: [PATCH v2 5/8] builtins/source: parse the -i option

[Chet Ramey]

On 5/16/24 11:36 PM, Robert Elz wrote:
>      Date:        Thu, 16 May 2024 11:36:50 -0400
>      From:        Chet Ramey <chet.ramey@case.edu>
>      Message-ID:  <613852f3-c9ef-43d8-821b-37be3d9e941b@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 implement
> BASH_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    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature