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


in reply to How to run perl5.21.3 as "perl"

Well ... having created the perl5.21.3->perl symlink from the terminal (as opposed to over the ssh network connection), I left that symlink in place.
That didn't make any difference to my existing ssh connection immediately - I still had 'which perl' reporting blead, but 'perl' loading the system perl. However, after a few path changes to run different perls, all suddenly started working perfectly when I came back to using blead over the ssh connection. Out of the blue, 'which perl' reported blead (as before) but 'perl' now loaded blead instead of the system perl.

Buggered if I know what the problem was, or what the solution was, but I'll try to re-create the problem next time I build blead.
If I can find something definitive, I'll update this thread with the info.

Thanks guys.

Cheers,
Rob

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

    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".

[reply]
[d/l]
      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
[reply]
      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.
[reply]

        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.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom