Description of problem: Once a command name has been resolved as being in a particular directory, bash fails to notice insertion of a command of the same name in a directory earlier in the PATH. It won't re-do its search even if you hit it over the head by removing the previously found command. Version-Release number of selected component (if applicable): bash-3.2-19.fc8.x86_64 How reproducible: 100% Steps to Reproduce: [tgl@rh2 ~]$ cd [tgl@rh2 ~]$ PATH=$HOME/bin1:$HOME/bin2:$PATH [tgl@rh2 ~]$ export PATH [tgl@rh2 ~]$ mkdir ~/bin2 [tgl@rh2 ~]$ cat >~/bin2/myscript #! /bin/sh echo "I am bin2/myscript" [tgl@rh2 ~]$ chmod +x ~/bin2/myscript [tgl@rh2 ~]$ myscript I am bin2/myscript [tgl@rh2 ~]$ which myscript ~/bin2/myscript [tgl@rh2 ~]$ mkdir ~/bin1 [tgl@rh2 ~]$ cat >~/bin1/myscript #! /bin/sh echo "I am bin1/myscript" [tgl@rh2 ~]$ chmod +x ~/bin1/myscript [tgl@rh2 ~]$ myscript I am bin2/myscript [tgl@rh2 ~]$ which myscript ~/bin1/myscript [tgl@rh2 ~]$ mv bin2/myscript bin2/myscript.x [tgl@rh2 ~]$ myscript -bash: /home/tgl/bin2/myscript: No such file or directory [tgl@rh2 ~]$ which myscript ~/bin1/myscript Actual results: As above Expected results: I expect bash to discard cached command locations anytime there is a change in the directories in PATH. I'm fairly sure this used to work correctly in FC6. Additional info:
Does hash -r help?
[ reads man page... ] Ugh. Don't tell me bash has adopted that bit of csh brain damage ... or am I just crazy, and it's been like that all along?
It's had that facility for a long time, but I've never known anyone to actually use it.
So... Is this still a bug then?
Maybe an enhancement request :-(. I really thought it paid attention to directory mod dates and did an auto rehash if they changed.
Adding Tracking keyword
For this purpose look at man page of bash. Section about shopt: checkhash. shopt -s checkhash solves your problem. Closing not a bug
Forgive me, shopt -u checkhash should be right.