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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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?)

  | 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" ?

Getting all that defined properly should be the most difficult part
of adding something like that.

kre