http://qs321.pair.com?node_id=1097890


in reply to Re: How to run perl5.21.3 as "perl"
in thread How to run perl5.21.3 as "perl"

The problem encountered, and the solution to it, is already acknowledged by aitap couple posts above.

When you enter a command, the shell has to successively perform a number of stat calls, each with a $PATH element (a directory) prepended. In order to cut down on those syscalls, a small short-circuiting cache is kept. In perl parlance, this would be $full_path{$name}.

You can check the current state of path cache with the "hash" builtin. To clear the cache, enter "hash -r". To refresh the cache on a particular command, try e.g. "hash perl".

Replies are listed 'Best First'.
Re^3: How to run perl5.21.3 as "perl"
by syphilis (Archbishop) on Aug 18, 2014 at 23:20 UTC
    To clear the cache, enter "hash -r".

    Ok - sounds like that must have been the problem.
    Odd that it hasn't bitten me before - but this is the first fix I'll try if it recurs.

    Acknowledgements to aitap, oiskuu and ikegami for raising/pressing this point.

    Cheers,
    Rob
Re^3: How to run perl5.21.3 as "perl"
by DrHyde (Prior) on Aug 19, 2014 at 10:37 UTC
    This probably made sense back in the good old days when disks were slow and memory expensive so you couldn't cache much. These days, it's a misfeature verging on being a bug. And I don't think it can even be disabled.

      Could this be the persuasion of one who subscribes to the school of thought that most, if not all, of the problems computational may be dissolved by the deft application of more RAM or more MHz or more Moore in general, to the pertinent parts of the technological apparatus involved?

      If so, please be advised that upon consultation of the relevant materials, or perhaps by hiring a consultant to perform such consultation, one might be apprised of a configurable asset of this exact designation; and furthermore, that a method of automatic profile-based customization might also be discovered. Thus one, presumably, might draw upon the resources of a competent systems administrator in order to execute said design by carefully encoding the user's .bash_profile (and .bashrc) with the invocation of set +h.

      </duh>

      *nix users often do not learn of this feature until years later, if ever. They don't need to. This is just a minor issue among the many bigger design problems

      Clarification for DrHyde.

      No, the path cache is not a bug, it's an overall improvement. If you have better ideas, please, do let the world know! Be sure to take all aspects into consideration, though. While RAM sizes have increased, so has the size of a typical distro. Weigh upon the implications of having e.g. NFS mounted /usr. This is certainly not the only case where user actions or interactions may subtly and surprisingly impact the working environment. Say, terminal report sequences getting stuffed into shell input, etc.

        Please try again, in English.

        As for 'set +h', that doesn't appear anywhere in my bash's manpage. +H does, but that's to do with shell history, not this cache.