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


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

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.

Replies are listed 'Best First'.
Re^4: How to run perl5.21.3 as "perl"
by oiskuu (Hermit) on Aug 19, 2014 at 15:51 UTC

    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.