Re: bash hash bug

[Linda Walsh]

Chet Ramey wrote:
> You probably have the `checkhash' shell option set.  
---
        Yup...didn't know about that
> Posix requires
> that the command hash table be transparent, in the sense that it can
> only be used if the hashed command corresponds to a valid pathname.
> It's designed to address the issue of execution failing when a hashed
> pathname is removed, even though there are files of the same name
> found in $PATH.
---
        FWIW, I am not using POSIX mode.  The manpage says that when
"a hashed value no longer exists, a normal path search is performed".
Resetting the hashed value with each command invocation would appear
to be incorrect behavior.

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

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

Some web findings:
---
I found this in the google cache of 
"osr5doc.ca.caldera.com:457/cgi-bin/man/man?hash+C"
at:
"http://66.102.7.104/search?q=cache:ynPLUbWPzDoJ:osr5doc.ca.caldera.com:457/cgi-bin/man/man%3Fhash%2BC+POSIX+standard+shell+hash+-bash+sh+OR+ksh+-alias&hl=en&gl=us&ct=clnk&cd=2";
===================
under section *Limitations*
...
Using hash with command names is unnecessary for most applications.
It may provide a performance improvement, obviating the need to use
$PATH to search for the location of a given command.

*Standards conformance*
hash is conformant with:
ISO/IEC DIS 9945-2:1992,
Information technology - Portable Operating System Interface (POSIX) - Part 2: 
Shell and Utilities (IEEE Std 1003.2-1992);
X/Open CAE Specification, Commands and Utilities, Issue 4, 1992.

SCO OpenServer Release 5.0.6 -- 1 August 2000
-----
        This seems to say that "hash" eliminates the need for checking PATH
(presumably when the command exists)

        Under a ksh reference page, the following warnings were listed:
NOTES

   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.
...
   4.  If a command that is a tracked alias is executed, and then 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
       continues to exec the original command.  Use the -t option of the
       alias command to correct this situation.
----
        These indicate that for conformance, the hash values or tracked
aliases should only be reset manually in the case where new commands
are added that would supersede the hashed command.  However, a non-existent
hashed value (or tracked alias), isn't an error that occurs (indicating that
in an "error" condition, the hash value is scratched and normal PATH lookup
ensues.

> And, as explained above, Bash interprets the Posix requirement to also
> mean that the hashed filename must be found in a $PATH lookup when
> checked.  
---
        I don't see that requirement -- only that the hashed value
must exist -- and when it doesn't, then resort to the PATH.  No wonder
bash commands execute so slowly under Windows -- it has to look through
all the directories every command.  I'm sure this isn't what was
intended.  I'm not sure I see a need for the "checkhash" shopt at all.
It's covered by the normal behavior of the standard.  If the user wants
to perform a PATH lookup on each invocation, they can turn off hashing.

        I'd expect this to give a good boost (multiple milliseconds/command;
perhaps saving tenths of a second/command if network lookups are involved) on
Cygwin where directory searches for executable commands are especially
expensive.

        Can this be fixed, Please?

Linda