As you can tell from the others' replies, the answer is not so simple, especially if the code is changing the current working directory. So my question is: what's wrong with the second return value from caller? If you show us an SSCCE that's representative of your actual code and that has a problem using caller, we can hopefully suggest a fix that works for you.

> what's wrong with the second return value from caller?

in my tests it's relative to the CWD at start, pretty much like $0.

Cheers Rolf
_{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
Wikisyntax for the Monastery}

in my tests it's relative to the CWD at start

Right, which is why abs_path((caller)[1]) should work in a lot of cases, but certainly not all, which is why I asked OP if perhaps they have one of those cases.

Of course, since FindBin tries to give a correct answer, it should be possible to simply steal its code, change it so it doesn't just work on $0, and then apply it to caller in a module's import - if someone hasn't done this already.

As you can tell from the others' replies, the answer is not so simple, especially if the code is changing the current working directory. So my question is: what's wrong with the second return value from caller?

The second return value from caller is the name of the script, with no path, same as $0. I see that Cwd's cwd, getcwd and abs_path return the path to the script with no script name, which is what I want. abs_path($0) returns the full path and script name.

I'd like this to be as bulletproof as possible. Should I use cwd, getcwd or abs_path? Should I use Cwd in a BEGIN block to assign the value of one of those functions to a global variable and if so what's the best was to do all that? Thanks

I see that Cwd's cwd, getcwd and abs_path return the path to the script with no script name

Again, please show some representative code - see also SSCCE. Functions like getcwd won't be the script's directory if the script is invoked with e.g. perl ../script.pl.

I'd like this to be as bulletproof as possible.

I know the feeling well and I often preach to make code as robust a possible. But this is one of those cases where experience has taught me that in 99% of my code, it's in fact ok to rely on $0 and caller, since most users are just going to be calling my script in a completely normal manner like perl script.pl.

In any case, code like I showed here will work a good portion of the time, important exceptions being when the script is read from STDIN or it's an -e oneliner. As I mentioned here, it would also be possible to adapt FindBin's code to work on caller.

But I suspect this may also be an XY Problem. Perhaps you can explain why you (think you) need this. A module shouldn't normally need to know the full filename of its caller. Looking at it another way, why can't the script use the more reliable FindBin to determine its own path, and then pass that as an argument to the module?

> I see that Cwd's cwd, getcwd and abs_path return the path to the script with no script name,

No it returns the current directory where you invoked perl. Well at best, a previous chdir will mess it up.

you should test with perl starting from another dir.

perl \tmp\script.pl

my $script = abs_path($0) is your best bet yet, just cut of the filename if you want the dir only

I don't think you need a BEGIN block if you put this at the very start of your module.

Cheers Rolf
_{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
Wikisyntax for the Monastery}

A combination of abs_path() and caller() works for me in one of my distributions:

use Cwd qw(abs_path);

my $script_path = abs_path((caller())[1]);

print "$script_path\n";
[download]

Here's a full working example:

Package.pm:

package Package;

use strict;
use warnings;

use Cwd qw(abs_path);

sub import {
    my $path = abs_path((caller())[1]);
    print "$path\n";
}

1;
[download]

Script:

use warnings;
use strict;

use lib '.';

use Package;
[download]

use v5.12;
use warnings;
use Cwd qw(abs_path);

say 'abs_path($0): ', abs_path($0);
[download]

--->

PS D:\transfer_D\d_temp> perl .\temp\tst.pl
abs_path($0): D:/transfer_D/d_temp/temp/tst.pl
PS D:\transfer_D\d_temp>
[download]

abs_path($0) gives wrong results if the script is invoked with a relative path and then changes directory. A robust solution is FindBin, which also resolves symbolic links:

use 5.020;
use warnings;
use Cwd qw(abs_path);
use FindBin;

say qq(Started as   '$0');
say q(abs_path is  '), abs_path($0), q(');
say q(FindBin says '), 
    qq($FindBin::RealBin/$FindBin::RealScript), q(');
say q(Changing directory...);
chdir '..';
say q(abs_path is  '), abs_path($0), q(');
say q(FindBin says '), 
    qq($FindBin::RealBin/$FindBin::RealScript), q(');
[download]

But FindBin emphasizes that it should not be used in modules, for the reasons they gave in their documentation. And the OP requested a way to find the path to the calling script from a module ... so as good as your solution is within a script, it's not the recommended solution to put into a module.

I tested my solution from a module too and it's unlikely such a chdir happens at compile time before a module is used.

Especially since a BEGIN { chdir ".." } also effects relative paths in @INC.

Granted I was too lazy posting two files.

So I'd speculate this approach is good enough for the OPs cases.

Cheers Rolf
_{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
Wikisyntax for the Monastery}

use Cwd 'getcwd';
[download]

This won't work. The current working directory can change away from the directory that the script is in. File::Find for example will do that "under the covers". There of course could also be cwd commands in the script too.

On Windows, $0 gives me the complete starting path of the initial script (not just the script name). Not sure what the OP wants past that.

Yes, the current working directory can change, but that's the best guess we have. The only thing better might be to get the script's cwd at the beginning, so we'd insert it in the BEGIN { } section, I guess.

In Windows, what happens often is you execute a script and Windows will supply perl.exe with the full path of the script. So, that's why in most cases in Windows $0 will yield a full absolute path but not always! If a perl script happens to be in the same directory where perl.exe resides and you were to open command prompt and enter "perl.exe myscript.pl" then $0 would only give you the name of the script. And in this case, if the script looks for the current working directory, then it would find itself.