tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH] Allow qualified filename (bar/foo) PATH searching.
On Wed, Oct 02, 2024 at 07:41:34AM -0400, Mouse wrote:
> >> I don't. You're breaking an existing facility even for people who
> >> choose ([p...]) to not use the new facility that came along with it.
> > ??? If the PATH_SEARCH_OPT is not set or does not have "Q", there is
> > absolutely no change.
>
> Okay, then I misunderstood: I thought you said that post-change,
> bar/foo would not work as before, that it had to be ./bar/foo:
>
> > Everything allowed now (if I drop---as I will---my dot specification)
> > remains possible after (except "bar/foo" being executed in current
> > dir; this will have to be, explicitely, "./bar/foo", [...].
>
> Presumably this was actually talking about the state with the
> environment variable flag turned on; it read to me as if you were
> talking about the case where it's not.
Yes: this divergence is only when the feature is on. If not on, 'bar/foo'
having a '/' is still not searched and is executed if found in the current
directory (POSIX behavior, unchanged).
So, to rephrase it, with the feature on:
- you have everything you have now + the possibility to use
sub-directories of the PATH alternatives, if you want to
organize your utilities like this and opt "in" for it (by
setting in the environment PATH_SEARCH_OPT="Q");
- only thing that changes when the feature is on: "bar/foo" is
searched, not executed in current working directory because it
is considered an "identifier" and not a locator (it says
"what"; it does not say "where"). With the feature, to have it
executed in cwd, you have to transform it in a "locator" i.e.
to prefix with './' for example in order for it to not be searched.
And the implementation is written so that by default, without the option, it's the
POSIX behavior and so that the option, whether used or not, does not
cost much in the shells or in the execvp(3) and posix_spawnp(3).
(If it was not, it would be a bug in my writing: it
has never been my intention to modify the default behavior; just to
add an option needing to opt "in"---not requiring to opt "out").
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Home |
Main Index |
Thread Index |
Old Index