I am sorry, this is confusing to me.
> "The list shall be searched from beginning to end, applying the filename to
> each prefix, until an executable file with the specified name and appropriate
> execution permissions is found".
>Shells without PATH hashing usually just test all possible PATHs by calling
exec() and stop when they reached the end of the PATH list or when the exec()
succeeded. The error code is usually the last encountered error.
Why would this be compatible with the standard? The standard clearly says,
that not only must a file be an executable, which means "
A regular file acceptable as a new process image file by the equivalent of the
exec family of functions" but also, to have appropriate permissions for the
user.
>The Bourne Shell introduced a PATH hash mechanism and behaves a bit different:
>It checks all possible path names via stat() and remembers the first path name
that is not a directory and that is executable for the shell user. The later
is checked by calling EUID access(), in modern systems this is:
faccessat(AT_FDCWD, name, X_OK, AT_EACCESS)
>This method has a minor problem: it cannot detect whether a binary file
containes executable code for a different CPU platform. So if you have such a
file in your PATH before the expected binary, the expected binary will not be
found.
>As you see, this is still compatible with the standard text ;-)
Why does this have anything to do with PATH hashing?
Why is this method compatible? As you point out yourself, it merely checks
permissions (by faccessat), but it does not check that the file is "executable"
(acceptable for exec...() ), so why would it be compatible?
What is the precise meaning of "acceptable"? That under some circumstances,
it is possible for an exec... function to succeed on this file? What if the
file fails, but with a different name, it might succeed - is it "acceptable"?
