bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bash hash question (bug? misunderstanding?)


From: Chet Ramey
Subject: Re: bash hash question (bug? misunderstanding?)
Date: Sun, 19 Nov 2006 13:46:49 -0500
User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025)

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    address@hidden    http://cnswww.cns.cwru.edu/~chet/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]