bug-bash
[Top][All Lists]
Advanced

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

bash hash question (bug? misunderstanding?)


From: Linda Walsh
Subject: bash hash question (bug? misunderstanding?)
Date: Sun, 19 Nov 2006 03:37:33 -0800
User-agent: Thunderbird 1.5.0.8 (Windows/20061025)

I'm having a problem in understanding the "hash" command in bash:
Starting from a clean hash list, I issue a regular command and it is
then placed in the hash list (NOTE, option "hashall

/> set -o|grep hash                    # check relevant setting
hashall         on                     # has default, "on" setting
/> hash -r                             # remove hash table
/> unalias ls                          # remove 'ls' alias
/> hash                                # verify hash table empty:
hash: hash table empty
/> ls /dev/null                        # use ls command
/dev/null
/> hash                                # reprint hash table
hits    command
  1    /usr/bin/ls                    # note hits=1
====
   I thought that hashing was a way to speed up program
access so it wouldn't have to be looked up in the path
again.  But it doesn't appear to be working from two different
perspectives.  First, I would expect the 'hit count' to increment,
but when I type 'ls' again, it doesn't increment the hit count
(continuing from above):

/> hash                                # reprint hash table
hits    command
  1    /usr/bin/ls                    # hits still 1
/> ls /dev/null                        # use ls again
/dev/null
/> hash                                # reprint hash
hits    command
  1    /usr/bin/ls                    # Uhoh, count still = 1!
===^====
  +-----------------------------------# would have expected a "2"

   Isn't count supposed to be implemented?

The second test case was seeing if the hashed path was
used in the absence of a PATH (testing in a subshell):

/> bash                                # start subshell
(2)/> unalias ls                       # get rid of ls alias again
(2)/> unset PATH                       # unset PATH (clears hash table)
(2)/> hash                             # verify empty
hash: hash table empty
(2)/> hash -p /usr/bin/ls ls           # manually add path for ls
(2)/> hash -l                          # list hash correspondences
builtin hash -p /usr/bin/ls ls
(2)/> ls                               # Try "ls"...
bash: ls: No such file or directory    # Uhoh?  why no execute?
(2)/> hash                             # reprint table
hits    command
  1    ls                             # count still 1
(2)/> hash -t ls                       # print path for 'ls'
/usr/bin/ls                            # appears correct as well

=================

   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! :-)
Linda











reply via email to

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