Date: Sun, 11 Apr 2021 22:27:19 +0100
From: Harald van Dijk <[email protected]>
Message-ID: <[email protected]>
| Okay, but that is a technicality. The pre-seeding is only permitted at
| startup time,
No, what it says is "an unspecified shell start-up activity".
"unspecified" means it can be anything. Anything includes starting
a thread which monitors what commands are about to be executed and
loads the hash table just in time. Or one which populates the hash table
with every possible command every tenth of a micro-second. Anything.
It is unspecified.
| so cannot depend on the contents of the script.
Of course, it can, the script is available at startup time of the
shell, the startup activity can read the entire script, parse it,
find all the command names and possible command names, and add them
to the hash table. Alternatively, it can examine PATH and load
every executable in every directory in PATH into the hash table.
zsh (seems to) do something like the latter.
| Replace gcc by any utility that is not hashed at startup
There are none (or none that can be found by a PATH search).
| Actually, if hashing commands is only allowed "as a result of this
| specific search or as part of an unspecified shell start-up activity",
unspecified remember...
| then after "hash -r" has executed, before a new command search has been
| performed, the hash table must be empty.
Not unless the specification for hash says so, and it doesn't.
| 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.
zsh comes close, it appears to empty the hash table on "hash -r", but
do anything at all, and it fills up again. And I mean fills. And I
understand that - if you're going to search the directories in PATH
over and over again, every time a command is executed, better to read
them once, and remember what they contain - no more useless I/O.
(I vaguely recall deciding that zsh read as many directories as needed
to find the command, and then stopped - getting a "command not found"
would result in everything possible from PATH now being in the hash table.)
| > 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 way PATH searches should be done.
| 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,
I know. This is irrelevant here. If this algorithm doesn't produce the
required results, that would be a bug, and like most bugs, if it is
considered serious enough, it can be fixed.
The important issue, is that the intent is to examine each element in
PATH, until we get success from exec(), (or ENOEXEC with a file we're
willing to treat as a script, and so exec a shell to interpret it).
So, if there is a /bin/gcc that is "#!/bad" and a later one in path
that is a real executable, we should exec the later one, right?
The dash (ash in general, at least originally) optimisation is simply
to note that if we read the directory, and didn't find the command name
there, then there's no point attempting to exec it from that directory,
that must fail. If between reading the directory and when the exec
attempt was made, someone inserted the command into one of the directories
that had been read, then we have a race - and as usual, sometimes one
wins, sometimes the other - if you're willing to bias the conditions
(handicap) you can force one result or the other (or just make one or
the other more likely), or you can make it even more unpredictable.
Nothing is wrong here, races have unpredicable results.
kre
