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 [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
