Re: sh(1): POSIX "Command Search and Execution"

[tlaronde%kergis.com@localhost]

On Sun, Sep 22, 2024 at 05:03:26PM +0700, Robert Elz wrote:
>     Date:        Sun, 22 Sep 2024 09:09:06 +0200
>     From:        tlaronde%kergis.com@localhost
>     Message-ID:  <Zu_Cknt2-c_T29yZ%kergis.com@localhost>
> 
>   | (whether your test about the first two chars, or the more restricting
>   | but simplest first an alphanumeric),
> 
> On that point, my reasoning is that I can imaging having 2 sets of
> (some perhaps) of the utilities, a basic set, and an enhanced set,
> living in sub-directories (of say, /usr/bin).   One of those would
> be in PATH as the default to use, but sometimes a user might want
> to use the other version as a test of something.
> 
> Those could be named basic/ls basic/cat ... and enhanced/ls enhanced/cat
> (etc), but that would then be a lot to type, so if it were me, the
> subdir names would be '-' and '+', so I might have /usr/bin/+
> in PATH, and then simply run
> 	-/cat file ...
> to use the basic one.   Not allowing non-alphanumerics as the first
> char would prohibit that kind of thing.
> 
> kre
> 
> ps: Of course, one can almost accomplish this with functions...
> 
> PATH_TO_BASIC_UTILITIES=/usr/bin/-
> PATH_TO_ENHANCED_UTILITIES=/usr/bin/+
> -() { ${PATH_TO_BASIC_UTILITIES}/"$@" ; }
> +() { ${PATH_TO_ENHANCED_UTILITIES}/"$@" ; }
> 
> and then use them as
> 	- cat ...
> 	+ ls
> instead of
> 	-/cat ...
> 	+/ls
> 
> and in that the "cat" part *is* allowed to have '/' in its name.
> 
> And if this wouldn't be good enough, then you also need to be
> concerned with how functions like execlp() etc work.   What you're
> proposing isn't really just a small(ish) change to sh, everything
> that does path searches needs to understand it (system(3) ...).

No: just the shell. Putting this in a C source will not be portable,
since the shell used for system(3) would not mandatorily understand
a "set -o xfilename" or whatever the name for the option.

Well, I will simply go for the test of '^/' or '^[.]\{1,2\}/' in order
to not prevent using more general names. But the aim is very simply to
keep PATH as it is but to allow to find (in my use case) "rast/in/ascii"
or "vect/in/dxf" with the rast subdir, typically in /usr/local/bin or in
/usr/local/sbin, holding all the raster utilities.

It could even be "kergis/rast/in/ascii" and so on, i.e. instead of
having all utilities put flat in the same dir, a package' utilities
could be put in its subdirs, still defining PATH with
"/usr/local/bin:/usr/pkg/bin:..." and so on.

This is just that.

The added bonus being that if one wants to test two different "packages"
providing the same filename utilities, the alternatives can be
installed concurrently and then, whether you qualify the version you
want to add, or you put in your PATH your choices in order of
precedence:

PATH="/usr/local/bin:/usr/local/bin/pkgbar:/usr/local/bin/pkgfoo"

Hence: pkgbar/acme as well as pkgfoo/acme will be found with the first
dir in PATH. But invoking "just" acme will select it in /usr/local/bin
if existing; if not in /usr/local/bin/pkgbar; and finally if not in
/usr/local/bin/pkgfoo.

The problem of conflicting utilities has arised, for me, with kerTeX
(my distribution of TeX) when some pkgsrc packages required TeXlive
components to be installed. KerTeX is installed in its own
subdirectories and one has to add these directories to the path, or to
fully qualify the utilities.
-- 
        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