2024年5月15日(水) 22:13 Chet Ramey <chet.ra...@case.edu>:
> On 5/14/24 4:48 PM, Koichi Murase wrote:
> > However, at the same time, I think the new option could be justified
> > from the viewpoint of language design. If we have a new namespace
> > ``BASH_SOURCE_PATH'' for the scripts to be sourced, it would be neat
> > to have an option to specify the namespace exclusively.
>
> Should these be the default semantics for BASH_SOURCE_PATH?
Even if the option is not supported, I think the default semantics
should still reference PATH and the current working directory as
fallbacks because some libraries may want to set BASH_SOURCE_PATH,
while some other libraries (such as an old library for <= 5.2 or a
POSIX-sh library) would still assume the current behavior of the
`source' builtin searching PATH and the current working directory. If
setting BASH_SOURCE_PATH would disable PATH and the current working
directory, those libraries cannot be mixed, which seems a troublesome
restriction.
> After all, if
> you want to search the current directory, put "." into the value.
Yes, that's technically correct. However, that requires every user or
framework to set BASH_SOURCE_PATH properly as
BASH_SOURCE_PATH=xxx:${BASH_SOURCE_PATH:-$PATH:.}
(unless without a specific reason). Otherwise, the setup can be easily
broken by a not-so-well-designed.library in a dependency.
> > `unset -v var' is not required.
>
> That was a POSIX invention as a compromise between implementations.
Hmm. Then, is the example of `unset' irrelevant?
