Bug 430179 - bash fails to track changes in location of an executable within the PATH
Summary: bash fails to track changes in location of an executable within the PATH
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 8
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: Roman Rakus
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-25 01:51 UTC by Tom Lane
Modified: 2014-01-13 00:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-11-13 15:43:10 UTC


Attachments (Terms of Use)

Description Tom Lane 2008-01-25 01:51:24 UTC
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:

Comment 1 Ignacio Vazquez-Abrams 2008-01-25 01:58:11 UTC
Does hash -r help?

Comment 2 Tom Lane 2008-01-25 03:11:10 UTC
[ 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-25 04:49:25 UTC
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 09:49:39 UTC
So... Is this still a bug then?

Comment 5 Tom Lane 2008-02-04 16:27:07 UTC
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-28 01:45:00 UTC
Adding Tracking keyword

Comment 7 Roman Rakus 2008-11-13 15:43:10 UTC
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 15:58:51 UTC
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.