Re: [PATCH] Allow qualified filename (bar/foo) PATH searching.

[<tlaronde%kergis.com@localhost>]

On Tue, Oct 01, 2024 at 03:26:06PM -0400, Mouse wrote:
> 
> > 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", or it will be
> > searched, not executed in the current dir; but as I have written, I
> > consider this an improvement---
> 
> I don't.  You're breaking an existing facility even for people who
> choose (whether from ignorance of its existence or from not finding it
> suitable for them) 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.

Where do you see there is a change? In the code allowing the feature,
there is a flag do_qfilename that is only non zero if the option is on AND if
the filename qualifies. If not, the behavior is absolutely unchanged.

This is just a possible option, not changing anything if it is not on,
and one has to set it for it to be on  (this option costs very little
in the binaries---shells, execvp or posix_spawnp; and in execution,
almost nothing if the option is not on, and very little if on to test
in the argument can be qualified as identifier i.e. no path directive
in it).

So I must say that I fail to understand why you are against a feature
that is only optional, does not change the traditional behavior by
default, and why you don't want to use the natural
hierarchy feature of a Unix filesystem to organize also utilities. To
add a group of files, that are related, you have only to mount a
directory. Why invent something else when it maps naturally there?

My guess it that mentionning URL and URI and thus dragging something
Internet related (while it was simply to say that I have not created
something: the difference between LARONDE/Thierry and where he is, is
nothing new) has made you hissing at the feature ;-) Forget
"Internet", this has nothing to do with it...
-- 
        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