Re: bash hash bug

[Linda Walsh]

Erp...  I probably thought it was getting rid of the problem I've had
in the past with ksh-type shells of retaining a bad-mapping to a file that
was no longer accessible.  A minor annoyance, admittedly, but one that
entangled me a few times several (or more) years ago...

Chet Ramey wrote:

Linda Walsh wrote:


If I have set the option, forgive me, but I'd sure rather
see that option *only* default to "on" _when_ Posix is set.


It defaults to off.  I'd check your startup files, including
/etc/profile and any interactive shell startup file in /etc,
like /etc/bashrc.

(This is not to say it could not behave better -- it can.  But
it's disabled by default.)

Chet



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash hash bug

[Chet Ramey]

Bob Proulx wrote:

>> Chet Ramey wrote:
>>> 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.)

I looked, and it can.  So performance will improve slightly, since there
doesn't need to be a redundant path search, and the `hit count', which is
just a coarse estimate of hashing effectiveness, will be more meaningful.

It was a bug, or at least a case of code no longer working as originally
intended.

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