bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Koichi Murase
Subject: Re: [PATCH v2 5/8] builtins/source: parse the -i option
Date: Thu, 16 May 2024 00:25:36 +0900

2024年5月15日(水) 22:13 Chet Ramey <chet.ramey@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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]