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

[Koichi Murase]

2024年5月17日(金) 4:36 Greg Wooledge <greg@wooledge.org>:
> On Thu, May 16, 2024 at 11:31:55AM -0400, Chet Ramey wrote:
> > On 5/15/24 11:31 AM, Koichi Murase wrote:
> > > Maybe it was not clear to use `source name' and `source -i name' to
> > > describe the idea. I meant I assumed the search domain being
> > >
> > > * BASH_SOURCE_PATH + PATH + PWD without the option
> >
> > It seems to me that this isn't useful.

I tried to convince myself about the behavior that the existence of
BASH_SOURCE_PATH disables PATH and PWD. However, after rethinking, I
still think there is a compatibility issue with it. I still think the
search domain of the source builtin being

* BASH_SOURCE_PATH + PATH + PWD without the option
* BASH_SOURCE_PATH with the option

> > The whole reason to have and use
> > BASH_SOURCE_PATH is not to use PATH; a fallback to PATH if something
> > isn't found in BASH_SOURCE_PATH doesn't allow that.

For this point, I'm convinced that only providing "BASH_SOURCE_PATH +
PATH + PWD" wouldn't satisfy the whole reason for adding
BASH_SOURCE_PATH. Maybe we need the option.

> > And if you're using
> > BASH_SOURCE_PATH, you have to set it, and if you want `.' in there,
> > add it.
>
> Yes, I'm inclined to agree with this.  If you want it to fall back to
> $PATH, you can append the contents of $PATH to BASH_SOURCE_PATH as well.
> You get the most control if BASH_SOURCE_PATH is used exclusively when
> it's set.

The problem is that this changes the global behavior of the `source'
builtin, and setting BASH_SOURCE_PATH breaks other libraries that
assume PATH.

On Thu, May 16, 2024 at 11:31:55AM -0400, Chet Ramey wrote:
> (from the user's perspective;
> I'm not sure what I think about a loaded `library' changing the global
> user settings by setting it),

If the loaded "library" is a single-file library, there is no reason
for the library to set BASH_SOURCE_PATH. However, the original
motivation for adding BASH_SOURCE_PATH is to provide a mechanism to
specify the directory of a library that consists of many files, where
only the files necessary for the current purpose are loaded. Maybe I
should call it such a library as "a set of libraries" or "a library
framework". Such a library framework for Bash wants to add its own
path to BASH_SOURCE_PATH.

However, another library framework can similarly set PATH to achieve a
similar effect (despite the problem of the name conflicts in the mixed
namespace with the executable files). Such a library framework can be
an old library framework designed for Bash < 5.3. Or it can be a
library framework designed for POSIX sh.

If setting BASH_SOURCE_PATH disables PATH and PWD (on which a library
framework for POSIX sh would rely) in the search for the conventional
use of the `source' builtin, it means that we cannot use the two types
of the library framework in a session or a program: i.e., library
frameworks utilizing BASH_SOURCE_PATH vs library frameworks for POSIX
sh. To allow the existence of both types of library frameworks,

a. The search can fall back to PATH and PWD when the path is not found
in BASH_SOURCE_PATH. When the library framework for Bash wants to
restrict the search, the library can use the option as `source -i'
.etc (the letter `i' can be a different one). The POSIX-sh library
framework can continue to use the plain `source filename' without the
option.

b. Another option would be to require everyone to include `PATH'
and `.' in BASH_SOURCE_PATH. However, if we require that, "the whole
reason to add BASH_SOURCE_PATH" is again lost. In addition, a later
change of PATH wouldn't be reflected in BASH_SOURCE_PATH that way.

c. Even another option is to require people not to globally set
BASH_SOURCE_PATH and only use it through `BASH_SOURCE_PATH=<some path>
source filename'. However, I anticipate that if we add this feature,
library frameworks or distribution bashrcs would start to set
BASH_SOURCE_PATH, which would break library frameworks assuming PATH.

d. Is there any better solution under the design that BASH_SOURCE_PATH
disables PATH and PWD even without the option?

I now changed my mind so that the `source' builtin should have a
separate way to restrict the search in BASH_SOURCE_PATH. While
`source' without the option continues to consider also PATH and PWD,
`source' with the option can disable PATH and PWD.

If BASH_SOURCE_PATH is required to disable PATH and PWD in the
conventional uses of the `source' builtin (in the form `source
filename' without the option), maybe I'm opposed to adding
BASH_SOURCE_PATH at all.

--
Koichi