Bug 430179 - bash fails to track changes in location of an executable within the PATH
bash fails to track changes in location of an executable within the PATH
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Roman Rakus
Fedora Extras Quality Assurance
: Tracking
Depends On:
  Show dependency treegraph
Reported: 2008-01-24 20:51 EST by Tom Lane
Modified: 2014-01-12 19:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-13 10:43:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Lane 2008-01-24 20:51:24 EST
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):

How reproducible:

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
[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
[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

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:
Comment 1 Ignacio Vazquez-Abrams 2008-01-24 20:58:11 EST
Does hash -r help?
Comment 2 Tom Lane 2008-01-24 22:11:10 EST
[ 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?
Comment 3 Ignacio Vazquez-Abrams 2008-01-24 23:49:25 EST
It's had that facility for a long time, but I've never known anyone to actually
use it.
Comment 4 Tomas Janousek 2008-02-04 04:49:39 EST
So... Is this still a bug then?
Comment 5 Tom Lane 2008-02-04 11:27:07 EST
Maybe an enhancement request :-(.  I really thought it paid attention to directory mod dates and did an 
auto rehash if they changed.
Comment 6 Jon Stanley 2008-03-27 21:45:00 EDT
Adding Tracking keyword
Comment 7 Roman Rakus 2008-11-13 10:43:10 EST
For this purpose look at man page of bash. Section about shopt: checkhash.
shopt -s checkhash
solves your problem.
Closing not a bug
Comment 8 Roman Rakus 2008-11-13 10:58:51 EST
Forgive me,
shopt -u checkhash
should be right.

Note You need to log in before you can comment on or make changes to this bug.