$^X

• $EXECUTABLE_NAME
• $^X

  The name used to execute the current copy of Perl, from C's argv[0] or (where supported) /proc/self/exe.

  Depending on the host operating system, the value of $^X may be a relative or absolute pathname of the perl program file, or may be the string used to invoke perl but not the pathname of the perl program file. Also, most operating systems permit invoking programs that are not in the PATH environment variable, so there is no guarantee that the value of $^X is in PATH. For VMS, the value may or may not include a version number.

  You usually can use the value of $^X to re-invoke an independent copy of the same perl that is currently running, e.g.,

          @first_run = `$^X -le "print int rand 100 for 1..100"`;
  

  But recall that not all operating systems support forking or capturing of the output of commands, so this complex statement may not be portable.

  It is not safe to use the value of $^X as a path name of a file, as some operating systems that have a mandatory suffix on executable files do not require use of the suffix when invoking a command. To convert the value of $^X to a path name, use the following statements:

          # Build up a set of file names (not command names).
          use Config;
          my $this_perl = $^X;
          if ($^O ne 'VMS') {
                  $this_perl .= $Config{_exe}
                    unless $this_perl =~ m/$Config{_exe}$/i;
                  }
  

  Because many operating systems permit anyone with read access to the Perl program file to make a copy of it, patch the copy, and then execute the copy, the security-conscious Perl programmer should take care to invoke the installed copy of perl, not the copy referenced by $^X. The following statements accomplish this goal, and produce a pathname that can be invoked as a command or referenced as a file.

          use Config;
          my $secure_perl_path = $Config{perlpath};
          if ($^O ne 'VMS') {
                  $secure_perl_path .= $Config{_exe}
                          unless $secure_perl_path =~ m/$Config{_exe}$/i;
                  }
  

Variables related to regular expressions

Most of the special variables related to regular expressions are side effects. Perl sets these variables when it has a successful match, so you should check the match result before using them. For instance:

        if( /P(A)TT(ER)N/ ) {
                print "I found $1 and $2\n";
                }

These variables are read-only and dynamically-scoped, unless we note otherwise.

The dynamic nature of the regular expression variables means that their value is limited to the block that they are in, as demonstrated by this bit of code:

        my $outer = 'Wallace and Grommit';
        my $inner = 'Mutt and Jeff';
     
        my $pattern = qr/(\S+) and (\S+)/;
     
        sub show_n { print "\$1 is $1; \$2 is $2\n" }
     
        {
        OUTER:
                show_n() if $outer =~ m/$pattern/;
     
                INNER: {
                        show_n() if $inner =~ m/$pattern/;
                        }
     
                show_n();
        }

The output shows that while in the OUTER block, the values of $1 and $2 are from the match against $outer. Inside the INNER block, the values of $1 and $2 are from the match against $inner, but only until the end of the block (i.e. the dynamic scope). After the INNER block completes, the values of $1 and $2 return to the values for the match against $outer even though we have not made another match:

        $1 is Wallace; $2 is Grommit
        $1 is Mutt; $2 is Jeff
        $1 is Wallace; $2 is Grommit

Due to an unfortunate accident of Perl's implementation, use English imposes a considerable performance penalty on all regular expression matches in a program because it uses the $`, $&, and $', regardless of whether they occur in the scope of use English. For that reason, saying use English in libraries is strongly discouraged unless you import it without the match variables:

        use English '-no_match_vars'

The Devel::NYTProf and Devel::FindAmpersand modules can help you find uses of these problematic match variables in your code.

Since Perl 5.10, you can use the /p match operator flag and the ${^PREMATCH}, ${^MATCH}, and ${^POSTMATCH} variables instead so you only suffer the performance penalties.