Re: bash hash question (bug? misunderstanding?)

[Chet Ramey]

Linda Walsh wrote:

>    So what's the deal?  Aren't hits supposed to be incremented?
> If a hash entry is setup, shouldn't that 1) take precedence over and
> 2) allow the command to be found, even in the absence of a PATH?
> 
>    This behavior was in my locally built bash:
> version 3.1.11(2)-release (i686-suse-linux)
>    and the standard Cygwin-distributed bash:
> version 3.2.3(5)-release (i686-pc-cygwin)
> 
>    If someone could clear this up, that would be great! :-)

You probably have the `checkhash' shell option set.  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.

When this option is on, bash has to check the hashed filename for
each hash lookup.  This essentially causes the hash entry to be
deleted and re-added each time, which resets the number of hits to 1.
(It could probably be done without the deletion and re-addition; I
should look at that.)

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.  Given the current wording of the standard, that might be too
strict.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                       Live Strong.  No day but today.
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/