Re: When a hashed pathname is deleted, search PATH

[Eric Blake]

On 03/14/2014 04:05 PM, Reuben Thomas wrote:

>>> Why doesn't bash just remove the hashed path and do a normal PATH
>> search? I
>>> have to remove it manually.
>>
>> Look at the description of the `checkhash' option to `shopt'.  It does what
>> you want; it's just not the default.
>>
> 
> Thanks. Why is it not the default? Shouldn't an optimisation (hashing PATH
> lookup) be transparent to the user by default?
> 

For that matter, POSIX requires the 'checkhash' behavior:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/hash.html
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

In particular:

"Once a utility has been searched for and found (either as a result of
this specific search or as part of an unspecified shell start-up
activity), an implementation may remember its location and need not
search for the utility again unless the PATH variable has been the
subject of an assignment. If the remembered location fails for a
subsequent invocation, the shell shall repeat the search to find the new
location for the utility, if any."

So the three ways to reset a hash without resorting to the non-portable
shopt are 'hash -r', 'PATH=$PATH', or causing lookup to fail - but bash
is not honoring the third way by default (I didn't test if bash in 'set
-o posix' behaves differently).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature