Re: bash hash bug

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Linda Walsh on 11/19/2006 5:10 PM:
>     From my searches, it seems that non-existent hashed files revert
> to PATH lookups, but otherwise remain intact.  Specifically, it appears
> that the the PATH var isn't consulted if a valid hash value exists.

POSIX states, under 2.9.1 Command Search and Execution, that for a simple
command that does not contain slashes, is not a special built-in, is not a
shell function, and is not in a list of particular utilities, that the
command to execute is subject to a path search, and that:

"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. 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."

In other words, assigning $PATH invalidates the hash, and that if the
hashed location fails, a full path search is performed again.  But other
than that, there aren't really any definitive requirements about how the
hash must behave.  POSIX also states that having PATH undefined leads to
implementation-defined behavior, so bash is in its right to do whatever it
wants when you unset PATH (be that preserve the hashed values, or
otherwise); it is only assignment to PATH, or calling 'hash -r', that
POSIX requires to flush a hash entry.

> 
>     Do you have some POSIX text that indicate otherwise?  It
> appears that re-initializing the hashed value each time is not
> POSIX compliant (besides making the 'hash' function worthless).

It is too POSIX compliant (since POSIX only states "may" instead of
"shall").  It is more of a question of quality of implementation than of
compliance.

> 
>    1.  If a command is executed, and a command with the same name is
>        installed in a directory in the search path before the directory
> where
>        the original command was found, the shell will execute the original
>        command.     Use the hash command to correct this situation.

Indeed, that is another detectable side-effect of hashing - an
implementation that uses the hash should consult the hash, even if another
candidate utility was added earlier in the search path.  But the wording
in POSIX makes it clear that this is implementation-dependent, so if you
plan on installing programs into your PATH, you need to reset the hash
(either by 'hash -r' or by 'PATH=$PATH') before reliably using that
newly-installed program.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFYSN/84KuGfSFAYARAjvKAJ9bX4tbXXpdAXqZXiWCLPno0SzprACeNOTJ
5JgVERlijHm5ik8QWOHe9Sg=
=ZnZA
-----END PGP SIGNATURE-----