On 11/04/2021 22:05, Robert Elz wrote:
Date: Sun, 11 Apr 2021 19:46:36 +0100
From: Harald van Dijk <[email protected]>
Message-ID: <[email protected]>
| Sure, that's why I then switched to a different example that did not
| have an earlier "command -v" to point out how this leads to inconsistent
| behaviour.
But while it is possible to (at least probabilistically - it is a hash table
after all, effectively a cache) ensure that an entry exists, it is not
possible to ensure that one doesn't.
Recall this part from POSIX (still 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),
That is, a shell is permitted to pre-seed the hash table at startup time,
and if allowed then, exactly when it happens between when main() of the
shell is first called, and when a lookup for a command is actually done,
is unknowable. That means it is OK for the shell to pre-seed the hash
table for a command when the command name is seen, and then it will be
there when the search for that command is done.
Okay, but that is a technicality. The pre-seeding is only permitted at
startup time, so cannot depend on the contents of the script. Replace
gcc by any utility that is not hashed at startup and you will still have
the same problem. Or, as you say, clear the hash table explicitly.
Even hash -r (which removes everything) doesn't guarantee that everything
isn't immediately replaced (with up to date values of course) before that
command even finishes.
Actually, if hashing commands is only allowed "as a result of this
specific search or as part of an unspecified shell start-up activity",
then after "hash -r" has executed, before a new command search has been
performed, the hash table must be empty.
I want to say this is a theoretical concern, that there are no shells
where hash -r is implemented as doing anything other than clearing the
hash table. I cannot prove this but will be quite disappointed if any to
turn out to do something else.
But all of this is really irrelevant, it is based upon a flawed assumption
about what is happening (and even what should happen).
What dash and the others, I presume, are doing, is not really
the "subsequent command" thing (that was just an interesting argument to
make), it is rather an implementation of the original Bourne shell
strategy (pre hash table), which was, more or less (not this code,
I don't write algol68, just a similar effect):
[...]
That is, find an entry for cmd in PATH for which exec() succeeds.
Only fail if there is none.
Yes, that is what dash is doing.
The addition of the hash table should allow that algorithm to run
faster (with the occasional problem when after a hash entry is
created, someone inserts an entry earlier in PATH than it was before)
but it should not normally change the outcome of that algorithm.
Well, that is sort of what dash does. dash takes an extra integer that
specifies which PATH component was hashed and uses that as the starting
point for the search, but otherwise it is the same algorithm. So if
PATH=/a:/b:/c and the hash table says x is found in /b, the search in
the shell child will look for /b/x, and if that fails, /c/x. It will not
search for /a/x unless the hash table is cleared.
This does not seem useful to me. If the command is no longer present in
/b, it should be checked in all PATH components. Commands may
legitimately move from /usr/bin to /bin by system upgrades just as well
as the other way around.
Cheers,
Harald van Dijk
