geoffleach has asked for the wisdom of the Perl Monks concerning the following question:

O Monks, enlighten your humble seeker of knowledge.

The Getopt::Auto module has a help feature that generates a help message based on the options that have been defined in the POD. The generated help message includes the program's path.

In testing this feature, I generate a help message and compare it to that generated by Getopt::Auto. The module gets its path from Perl's caller builtin - caller, the call takes place in the import phase.

This works fine on Unix-based platforms. However on Windows Vista (MSWin32), the path generated with File::Spec->catfile() uses backslashes, while caller appears to use the Unix-standard forward slash. (Tested on Perl 14)

Specifically, the test output for test 02-internals_magic.t is

t/02-internals_magic.t # generated by caller() ^ not t\02-internals_magic.t # generated by File::Spec->catfile() ^ as expected

Is this the way that caller works?

I'd appreciate receiving the MSWin32 output from following code. Note that it must be run from at least one directory level away from the source.

print "$0 running in Perl $^V\n"; foo::t(); package foo; sub t { @c = caller; print "Caller[1] is: $c[1]\n";}

Replies are listed 'Best First'.
Re: Perl's caller builtin
by ikegami (Patriarch) on Jul 30, 2011 at 18:24 UTC

    while caller appears to use the Unix-standard forward slash.

    Not quite.

    >perl ./a.pl ./a.pl running in Perl v5.14.0 Caller[1] is: ./a.pl >perl .\a.pl .\a.pl running in Perl v5.14.0 Caller[1] is: .\a.pl

    I'd appreciate receiving the MSWin32 output from following code.

    How can the path used to open the file not be a MSWin32 path? Windows accepts both "\" and "/" as directory separators.

      And so, my knowledge of Windows is vastly expanded :-). Thanks.
Re: Perl's caller builtin
by Corion (Patriarch) on Jul 30, 2011 at 18:24 UTC

    How bent are you on testing that the resulting test matches exactly? Wouldn't it be enough to match that the resulting error message contains

    02-internals_magic.t at line ...

    I would use a regular expression to confirm that the string ends with what you want, instead of trying to cater for every native file system name. Also, maybe you want to avoid File::Spec if you want Unix-semantics filenames. For unixish semantics (as Perl uses in its error messages), you can always concatenate with slashes.

      Not bent at all, as it turns out.

      Clearly, the validity of the test is not determined by the path from which it is run. On with the regex!

      Thanks.