See the discussion at Re: How do I get the full path to the script executing?.

In Perl, the automatic variable $0 in some operating systems gives the full path of the currently executing Perl script. In others you just get the name of the file that is executing. The module Cwd will give you the "current working directory". Just see attached code... executed on a Windows 32 bit XP system and a 64 bit Linux system. The combination of basename() and cwd() will always work on all OS'es.

#!/usr/bin/perl -w
use strict;

use File::Basename;
use Cwd;

print "dollar 0 is $0\n";
print basename($0), "\n";
print "current working directory is: ",cwd(),"\n";

__END__
On Windows, you get:
  dollar 0 is C:\TEMP\exename.pl
  exename.pl
  current working directory is: C:/TEMP

On Linux, you get:
   dollar 0 is ./exename.pl
   exename.pl
   current working directory is: /home/xxx/yy
[download]

Update: Note the Windows cwd() results in "C:/TEMP"! Windows allows the use of the forward-slash ('/') in almost all situations. There is a situation where that is not true (the backslash '\' is required), but I can't remember at the moment what that is. Some Monk will probably enlighten us. My main point is that '/' almost always works to join paths on Windows.

On some Unix-systems (Linux among them) you can actually assign to $0 to change the way the process shows up in the process list (I've seen that done e.g. to prevent passwords that are supplied on the commandline to show up with ps).

I now wonder if you changed your $0 to something else - would there be any way to recover the true script-path again?

I was quite astonished! I put an $0 = 'xyzzy"; statement in my Perl code and I'll be, ps -ef shows xyzzy in the process table! I am shocked and don't know why this could happen! I would have never thought that $0 was a writable variable. My brain was thinking along the lines of C and its char** argv, which is normally used as "read only", but that's not what is happening here.

I guess you could save: my $saved = $0; or make a { local $0; $0 = 'xyzzy'; other stuff}, but I'm not sure why that would be useful?

concatenate the result of cwd() and basename($0) with intervening "/" to get the full path of the script in a OS independent way.

What does the value of Cwd::cwd() have to do with the path of the Perl script? There's no general correlation.

C:\WINDOWS>type C:\Temp\WhereAmI.pl
#!perl

use strict;
use warnings;

use Cwd;
use English;
use File::Basename;

my $basename = File::Basename::basename($PROGRAM_NAME);
my $abs_path = Cwd::abs_path($PROGRAM_NAME);
my $dirname  = File::Basename::dirname($abs_path);
my $cwd      = Cwd::cwd();

print "\$PROGRAM_NAME:                            $PROGRAM_NAME\n";
print "\$File::Basename::basename(\$PROGRAM_NAME): $basename\n";
print "\$Cwd::abs_path(\$PROGRAM_NAME):            $abs_path\n";
print "\$File::Basename::dirname(\$abs_path):      $dirname\n";
print "\$Cwd::cwd():                              $cwd\n";

exit 0;

C:\WINDOWS>perl \Temp\WhereAmI.pl
$PROGRAM_NAME:                            \Temp\WhereAmI.pl
$File::Basename::basename($PROGRAM_NAME): WhereAmI.pl
$Cwd::abs_path($PROGRAM_NAME):            C:/Temp/WhereAmI.pl
$File::Basename::dirname($abs_path):      C:/Temp
$Cwd::cwd():                              C:/WINDOWS

C:\WINDOWS>
[download]

Yes, simply Cwd::abs_path($0) appears to work the best. My previous post is not right. I did some more testing but there are a lot of cases and I suspect that there are quirky border cases out there.

So,
to get name of program: File::Basename::basename($0);
to get absolute path: Cwd::abs_path($0); NOT Cwd::Cwd()
To be portable, you must use abs_path() before doing anything that changes the current working directory, eg chdir().

I tested on Windows XP and Fedora Linux.
$0 on Windows was the full absolute path of the executing script, but with Windows style "\" instead of "/".
$0 on Linux was essentially what was typed into the shell to run the script. Something like this: "../test/whereami.pl" gave exactly that for $0.

When using Cwd::abs_path($0), on Windows the backslashes ('\') were converted to forward slashes ('/') - the full path stayed the same since $0 was the full path to begin with. A chdir() on Windows had no effect upon the result of abs_path().

On Linux, abs_path does some text massaging of rel2abs()'s output which itself a result of using Cwd::cwd() so if working directory is changed, abs_path() will be wrong. (oh, abs_path() probably doesn't call rel2abs() but it looks like it does whatever rel2abs() does. Oh, the rel2abs() function in File::Spec... in my Unix test case it concatenates $0 onto what cwd() says. So in my test case, >cd b >../test/whereami.pl, you get a path like: blah../marsh/b/..test/whereami.pl. This is a valid path, but the detour through unrelated directory b is not needed. abs_path() evidently takes this path and eliminates the trip through dir b.

This is also one of those cases where "use English;" just serves to further confuse the reader because:
$program_name = File::Basename::basename($PROGRAM_NAME); because of course $0 is NOT the program's name. I don't think there is a good "english name" for $0 because "its sometimes this and sometimes that" is hard to express in one short name!

I'd recommend checking out the Cwd module. It's got multiple functions to get that information in different formats.

Cwd is usually used to find the current working directory - not necessarily the same as the directory in which the script resides.