From prlw1@cam.ac.uk

Our perl package installs perl as "perl" and as a binary with the
version number in the name, as hard links, e.g.​:

$ ls -li /usr/pkg/bin/perl*
18781554 -rwxr-xr-x 2 root wheel 10752 May 9 09​:14 /usr/pkg/bin/perl
18781554 -rwxr-xr-x 2 root wheel 10752 May 9 09​:14 /usr/pkg/bin/perl5.22.2
...

The output of the following script comes as a surprise​:
$ cat foo.pl
#! /usr/pkg/bin/perl
print "$^X\n"; # $EXECUTABLE_NAME in English
$ ./foo.pl
/usr/pkg/bin/perl5.22.2

Breaking the hard link with
# mv /usr/pkg/bin/perl5.22.2 /tmp; mv /tmp/perl5.22.2 /usr/pkg/bin

gets the expected​:
$ ./foo.pl
/usr/pkg/bin/perl

This matters for scripts which look for themselves in the process table.

I believe that $^X should return the path perl was initially invoked with.

From zefram@fysh.org

Patrick Welche wrote​:

I believe that $^X should return the path perl was initially invoked with.

The path that was passed to execve(2) is not available, and even if
it were available it might not be absolute. argv[0] is available, but
not necessarily accurate or absolute. perl therefore prefers to read
the link /proc/self/exe. This refers accurately and absolutely to the
executable file, but by nature has no preference among the file's names.

We should not compromise the accuracy or absoluteness, where the means
to get these are available. In principle we could add some logic to
see whether argv[0], if different from readlink(/proc/self/exe), is
an absolute pathname for the same file, and to then prefer that name.
But that sounds like more trouble than it's worth. $^X is meant for
practical purposes; if you're after the cosmetic effect of using a
particular name for the file then $^X is the wrong tool for your job.

-zefram

The RT System itself - Status changed from 'new' to 'open'

@iabyn - Status changed from 'open' to 'rejected'