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


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

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.

Replies are listed 'Best First'.
Re^5: How to run perl5.21.3 as "perl"
by DrHyde (Prior) on Aug 21, 2014 at 11:59 UTC

    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.