While browsing the Debian bug database for bash I came across your bug submission from June 2008.
Bernhard Kuemel wrote: > I compiled and installed esniper from upstream source while > having installed the debian esniper package. So I have > /usr/local/bin/sniper and /usr/bin/esniper. Even though > /usr/local/bin is before /usr/bin in $PATH /usr/bin/esniper > is preferred by bash. When I have bash running within mc it > works correctly. You do not mention 'hash' anywhere in your report and therefore I assume that you were unaware that bash hashes command paths. If your shell previously located esniper at /usr/bin/esniper then it will subsequently be hashed there, will remember that location, and will not check PATH for other occurrences that were installed later. In order to tell bash that its hash table is stale you would give the 'hash -r' command to have it "rehash" its command paths. (And of course starting a new bash process starts off with an empth command hash too.) $ type esniper esniper is hashed (/usr/bin/esniper) hash -r $ type esniper esniper is /usr/local/bin/esniper What you are seeing does not seem like a bug in bash but simply a misunderstanding of how bash handles command hashing. Note: See also the documentation for 'shopt -s checkhash' too. Personally I always set that in my ~/.bashrc file. Bob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
