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

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

    Date:        Tue, 1 Oct 2024 08:51:12 +0200
    From:        tlaronde%kergis.com@localhost
    Message-ID:  <Zvub4ORdYFQoklP6%kergis.com@localhost>

  | For {get,set}progname and err*()/warn*(), it would need an option to
  | not truncate to last component.

err() and warn() just use the results of setprogname() - which on NetBSD
just happens, and doesn't need to be explicit, actually calling setprogname()
is a no-op, programs do it so they are portable to other systems -- so
there's no easy way to know what to truncate (it is done long before any
options get parsed, or main() even starts running), and what not to - though
one might only truncate

	if (argv[0][0] == '/' || (argv[0][0] == '-' && argv[0][1] == '/'))

as when a path search is done, argv[0] gets set to the name that was
searched for, not the path under which it was found, so if one were
to run foo/bar using this mechanism (PATH searching) then argv[0]
would be "foo/bar" not "/path/to/foo/bar".    That is for executables,
for scripts (the interpreter, /bin/sh or whatever is being used)
sets the argv[0] that the script gets to view ($0 in the case of sh)
and could do anything needed - but for that the interpreter needs to
be told the full path name to the script (if located via a PATH search),
so it can be opened.   It would be the (many) different interpreters
which would need to be modified (all that expose argv[0] to their scripts).

But for executables, where getprogname() is of relevance, since foo/bar
doesn't start with a '/' it could be left intact (but that's not what
currently happens, so it would mean a change).

And all of that is assuming that any change is needed at all, which I
doubt.   If I run /usr/bin/printf getprogname() returns "printf".
If I run ~/bin/printf getprogname returns "printf" - why should it
be different if I do PATH=~:whatever:else and then run "bin/printf" ?

The final component is enough, whether invoked as "foo" "/path/to/foo"
or "to/foo" - all should be treated the same way.

  | For {base,dir}name(), it would need an option telling to search the
  | first prefix in PATH matching and to return the prefix as dir and the
  | rest as identifier.

Certainly not, there is no need to modify either of those, they are
string manipulation routines, and don't have anything to do with path
names at all (though their definition and common usage makes them appear
to be that).   They certainly should *never* consult PATH.

  | For realpath(), for me, nothing has to be done:

Agree there, that one also does what it is designed to do, which is
work on arbitrary pathnames and provide the canonical path name to
reach the same file.   Nothing at all to do with PATH searches.

kre