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

[tlaronde%kergis.com@localhost]

On Sun, Sep 22, 2024 at 04:38:52AM +0700, Robert Elz wrote:
>     Date:        Sat, 21 Sep 2024 09:47:09 +0200
>     From:        tlaronde%kergis.com@localhost
>     Message-ID:  <Zu55_br1MGfBdSNk%kergis.com@localhost>
> 
>   | one can reach the answers interpolated searching for '^#TL':
> 
> My mail reader colours quoted text (quoted the standard '>' way you did)
> in red, and new text in black, so finding your parts was easier than
> that... (but thanks anyway).
> 
>   | Then could you point it out to the committee? ;-)
> 
> I can (or could) - I'll see when I get around to participating there
> again next.
> 
>   | Could the committee use something like:
>   |
>   | "if the system has implemented the utility as a built-in or as a shell
>   | function, and the built-in or function is associated by the
>   | implementation with the directory in which the search succeeded, the
>   | related built-in or function masks the utility and is invoked in its
>   | stead at this point."
> 
> If/when I suggest changing things, I'll include that suggestion
> (with attribution to you of course).
> 
> 
>   | function of a related chunk brings the others. (Is changing the
>   | definition of PATH clearing these from the hash table?)
> 
> no, once added they are just sh functions, the same as any other, but
> it might not be too difficult to make something like that happen if it
> were to be useful.
> 
>   | I think it could be added without much ado, but only via setting an
>   | option
> 
> Yes, I doubt it would be difficult to add, what matters is designing
> the desired semantics (eg: should these things search PATH to locate
> the commands, or would some other variable be a better idea?)

PATH will do. All in all, its the logic: the filename is simply more
"qualified" by the dir (whatever level) prefix. But there is nothing special
about it.  And I would argue this is Unix like: filesystems are organized by
hierarchical dirs. Allow one to sort the utility and use the
hierarchical nature of a Unix filesystem.

> 
>   | and restraining the feature to pathname with at least a '/'
> 
> Yes, definitely or normal command searches would fail.
> 
>   | and starting by an alphanumeric (hence, ./bar/foo will not be
>   | searched for).
> 
> but that might be overly restrictive - just skipping commands that
> start "/", "./" or "../" is probably enough.   But deciding if you need
> to handle multi-level commands (a/b/c/d) or only 2 (a/b) might be
> worth some thought - also exactly what are the semantics of the
> search, if we are looking for bar/foo and find a directory "bar"
> then if foo exists in that directory, good, but if it doesn't?
> Does the search then fail, or does it continue to look for another "bar".
> If the search eventually fails, is the shell to fall back to attempt
> "execl("foo/bar", ...) or is that simply "not found" ?
> 

It seems to me that the simplest handling would be to treat the
pathname chunk exactly as a filename. That is, if the option is set
and the pathname chunk has at least one '/' and matches the conditions
to be recognized as such an extended/qualified "filename" (whether your
test about the first two chars, or the more restricting but simplest first an
alphanumeric), it skips the first treatment (of a pathname with at
least a '/'), and is treated exactly as a filename without any slash.
From a cursory look, it seems the present code could handle it without
problem.

Is an option, settable by set, and conflicting with "posix" (if posix
is set, the option can not be set; if posix is set after, the option
is reset to off) with a name of "xpathsearch" or "xfilename", would
seem acceptable? I will find some time next week to try to add 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