On 11/04/2021 16:33, Robert Elz wrote:
Date: Sun, 11 Apr 2021 13:25:46 +0100
From: Harald van Dijk <[email protected]>
Message-ID: <[email protected]>
| > My tests show that ksh, bash, yash, mksh do not find gcc in that case.
|
| Huh. My tests with ksh were with 93v, it's possible different versions
| behave differently.
I see the same results as Joerg. I'm using ksh93u.
Interesting. Will need to re-test with that later.
[...]
Note that POSIX says (this is from 8 D1.1 XCU 2.9.1.1 1. e. i.)
Once a utility has been searched for and found (either as a result
of this specific search or as part of an unspecified shell start-up
activity), an implementation may remember its location and need not
search for the utility again unless the PATH variable has been
the subject of an assignment.
Aside from the lack of mention of hash -r there, that much is fine. It
goes on:
If the remembered location fails for a subsequent invocation,
the shell shall repeat the search to find the new location for
the utility, if any.
Note: "fails" not "utility is is not found at" or similar, and "the shell
shall".
What it means in these circumstances to "repeat the search to find the
new location for the utility, if any" is less clear - but a reasonable
interpretation (adopted by about half the shells) is that it should look
through PATH, see if it can find a copy of the utility that does not
fail to invoke, and invoke that one. Also note that it does not say
that it is OK to replace the remembered location with that of the newly
located command.
This only applies when a remembered location exists at all, though. If
no remembered location exists, the invocation is not a "subsequent
invocation" and the paragraph does not apply.
Then, if you accept that, for consistency, "the shell shall repeat the
search" can only mean to repeat the full search and again stop at the
first file with execute permissions, as it would be batshit crazy to
have a shell that, when presented with "gcc; gcc", for the first gcc
issues an error because /bin/gcc cannot be executed, and for the second
gcc to find /usr/bin/gcc because /bin/gcc failed to execute. I am pretty
sure you are not suggesting that that is reasonable, but I think that is
a bad consequence of your interpretation of the wording.
And if "shall repeat the search" does refer to the exact same search
that was initially performed, then "Once a utility has been searched for
and found [...] an implementation may remember its location" arguably
applies to that repeated search as well, but that is less clear. You
have asked questions about that later on. They are good questions to
think about. I am not sure about those yet, so am skipping them for now.
I agree with that. Nothing else is rationally possible, except failing
to exec the command (like bash and the ksh's do), but it is hard to
explain how failing to run a command when one that is runnable exists
in $PATH, is a better outcome than running it.
I think that is easier to explain than the other way around, myself.
Suppose PATH is intentionally modified so that an uClibc-linked version
of GCC appears first in $PATH, but the user messed up, the dynamic
linker of uClibc is actually not yet installed, or is installed in the
wrong location. It is clearly the user's intention to execute the
uClibc-linked version, and attempting to execute that and reporting the
error is what bash and others would do. Silently executing some other
version that the user didn't want is, in my opinion, doing the user a
disservice.
(Disclaimer: I am not certain whether all shells would treat this
exactly the same way as the '#!/bad' example.)
Cheers,
Harald van Dijk
