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

[Chet Ramey]

On 5/17/24 11:40 AM, Robert Elz wrote:
>      Date:        Fri, 17 May 2024 10:09:06 -0400
>      From:        Chet Ramey <chet.ramey@case.edu>
>      Message-ID:  <e44b4d4f-2ac5-495e-8681-992168e50925@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 extended semantics I had in mind would simply extend not searching PATH
(there is no other PATH variable to search right now) to not searching PATH
or BASH_SOURCE_PATH.


>    | and we could make that part of the semantics of BASH_SOURCE_PATH.
>
> That exactly was the suggestion.

OK, if it ever gets added.



> 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).

Believe it or not, I had thought of that as well. It sidesteps the whole
BASH_SOURCE_PATH variable brouhaha altogether.

> 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).

Interesting, but obscure and potentially problematic if the filename is
stored in a variable that might be empty, e.g.,

source -p path $FILENAME

(yes, you know people are going to do that.) I would prefer to require

source -p $BASH_SOURCE_PATH filename

or whatever the user wants to call it, for clarity.

> 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).

I've just about given up on BASH_SOURCE_PATH anyway.

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

If someone else wanted to implement one of the BASH_ variables, I'd be
willing to talk about supporting a different name (as a synonym, in bash's
case) if we wanted to potentially standardize it. Some variables, like
SRANDOM, are already like that, and available for other shells to
implement.

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