|
Re^3: Do modules know the callers full path?
by haukex (Archbishop) on Feb 15, 2023 at 21:30 UTC
|
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?
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
In that case, I'd say the answer is: it depends. Is the data something that the module can download automatically, or does it need to be curated by hand? If it can be done automatically, one could consider caching it in a ~/.something directory. For system-wide installation, just as an example, Debian packages like tzdata store the zoneinfo in /usr/share.
While it might be possible, I'm not sure I would recommend storing the data alongside the module directly (i.e. in the same directory or even in its __DATA__ section) if one wants the data to be updatable independently of the module. The reason I think so is that the typical expectation of a Perl user / developer would be that the module directories are generally only affected by the installation of modules, and if the module were to change its own files that might lead to inconsistencies, e.g. if modules are re-installed.
With answers to the above questions, we could probably narrow down the suggestions even more.
Of course, if the data only changes once a year, I think it's also a reasonable idea to include the data in the module and release a new version of the module when the data changes.
Another point: I don't see why such a module would need to know its callers path? "The info is embedded in the module DATA" sounds like the module wants to modify its own code, not the caller's? A module can use __FILE__ to get its own filename, and if the @INC directory it is located in is an absolute path, __FILE__ should be an absolute path as well.
| [reply]
[d/l]
[select] |
|
|
|
|
Re^3: Do modules know the callers full path?
by LanX (Saint) on Feb 15, 2023 at 21:24 UTC
|
> 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.
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
> Of all the things I was trying only abs_path($0) and abs_path((caller)[1]) DWIM.
Really? Careful!
They are different if your module is used by another intermediate module and not the root script.
> It's fun watching you guys hash it out though,
This is also hard, because you leave room for interpretation.
Only you can tell us what you exactly want.
| [reply]
[d/l]
[select] |
|
|
|
|