Is Perlbrew not an option for you? If it is, I would recommend it. Takes the head-scratching out of having multiple Perls on my machine and prevents me having to worry about messing up the system Perl.

Just a thought...

I don't know exactly what's causing the problem, but a workaround might be to set up a shell alias. Most Unix shells (bash, tcsh, etc) support them, though the syntax to define them varies from shell to shell, so you'd need to check your shell's manual.

I was half expecting it might have been something obvious that I was missing.
Something in your reponse made me suddenly think "hang on ... I'm doing this over an ssh connection". So I decided to see whether the same problem existed when I sat at the computer's terminal (using identical path) and accessed it directly ... and it didn't !! Everyting works as expected when I'm sitting at the terminal.

But what makes it even weirder is that I have other perls under ~, and those perls *are* accessible as "perl" over the ssh connection.
For example:

sisyphus-sis@debian-sis:~$ echo $PATH
/home/sisyphus-sis/perl520-m64-multi/bin:/usr/local/bin:/usr/bin:/bin:
+/usr/local/games:/usr/games
sisyphus-sis@debian-sis:~$ which perl
/home/sisyphus-sis/perl520-m64-multi/bin/perl
sisyphus-sis@debian-sis:~$ perl -le 'print $^X'
/home/sisyphus-sis/perl520-m64-multi/bin/perl
sisyphus-sis@debian-sis:~$
[download]

No problems with that (or any of the 7 other installations of) "perl" over the ssh connection. It's just the bleadperl that won't play ball.
Thanks for the reply tobyink

Cheers,
Rob

Are you certain that you don't have a shell alias for perl, which points to /usr/bin/perl?

Are you certain that you don't have a shell alias for perl, which points to /usr/bin/perl?

I think that if that was the case then the other 7 perls that I have installed also under my home directory would be likewise affected ... but they're not.

Cheers,
Rob

which is a utility rather than a shell command in sh and sh-derived shells. As such, it knows nothing of the shell's aliases and such. It just searches the path.

To find out what bash will execute when you type perl, use type perl. It will tell you if it's an alias. It will tell you if it's "hashed", which is to say cached. The cache can be cleared using hash -r.

Update: Added "in sh and sh-derived shells".

bash doesn't have a built-in which? tcsh does, which is quite handy...

$ which perl
/home/tai/perl5/perlbrew/perls/perl-5.20.0/bin/perl
$ which ls
ls:      aliased to ls --color=tty
$ which which
which: shell built-in command.
[download]

toby döt ink

You seem to have stopped reading my post before the second paragraph. The whole point of my post was to show how to do what tcsh's which does.

$ type perl
perl is /home/ikegami/usr/perlbrew/perls/5.20.0t/bin/perl

$ perl -e1

$ type perl
perl is hashed (/home/ikegami/usr/perlbrew/perls/5.20.0t/bin/perl)

$ type ls
ls is aliased to `ls -F -1 --color=auto'

$ type type
type is a shell builtin
[download]

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

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

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.