I recently was looking into a CPAN tester report

- MSWin32-x86-multi-thread-64int / 5.20.2:
- FAIL http://www.cpantesters.org/cpan/report/bc273757-6c01-1014-a765-afcf632b568brt
that has me a bit confused.

The last win32 version I'd tested with was a bit ago
@ in 5.14 and it didn't have this problem.

But the issue(s) that seem to be causing a problem
in the test (I'm guessing), is that I don't "requote"
existing '\' (BackSlashes/BS's) in an existing perl-loc or path ($^X and PERL5LIB/@INC).

Notice both the PATH is displayed in Windows format
with BS's and semicolons:

PATH = C:\WINDOWS.0\system32;C:\strawberry\c\bin;\

But the more bothersome one(s) is(are) is the PERL5LIB+@INC,
and  the "Perl.exe" $^X var.

The PERL5LIB var is best displayed in the '@INC' as it shows
both CPAN paths and strawberry perl paths:

For @INC it shows the above paths as well as @INC: C:\cpan\build\Types-Core-0.1.4-8EUNyT/blib/arch C:\cpan\build\Types-Core-0.1.4-8EUNyT/blib/lib C:\cpan\build\Xporter-0.1.2-OWKF3Q/blib/arch C:\cpan\build\Xporter-0.1.2-OWKF3Q/blib/lib C:\cpan\build\mem-0.4.5-dZP9Gl/blib/arch C:\cpan\build\mem-0.4.5-dZP9Gl/blib/lib C:/Strawberry/perl/site/lib C:/Strawberry/perl/vendor/lib C:/Strawberry/perl/lib .

Notice in INC, the Strawberry paths are all done with
forward slashes (as I'd expect to be consistent with
past versions and quoting conventions.

In the 2nd displlay of PERL5LIB, it has the path in double
quotes listing only the CPAN paths.
A simple perl prog seems to show the problems:

perl -we 'use strict;
# nobuf-output as described in PrlBstPrct
my $test="C:\this/and/that in perl @ $^X";
printf "%s\n", $test;
$^X = "C:\Strawberry\perl\bin\perl.exe";
printf "5.20 path for perl: $^X???\n";
print "INC:\n";
printf "    %s\n", $_ for(@INC);
Unrecognized escape \S passed through at -e line 6.
Unrecognized escape \p passed through at -e line 6.
Unrecognized escape \p passed through at -e line 6.
C:      his/and/that in perl @ S:\Dwimperl\perl\bin\perl.exe
5.20 path for perl: C:Strawberryperinperl.exe???

Note in the above (5.14), the only path that had
a problem was the one I manually set to have
BS's. I.e. $^X and @INC had path-seps set
to FS.  But according to the CPAN-smoker test
report, 5.20 doesn't do this.  Is that right?

I know how to work around the problem, BUT, it seems
like defaulting to internal path strings that contain
a mix of forward and back slashes is likely to cause
a fair amount of surprise.

Is it really the case, that any path strings must
now be requoted (or not used inside any double-quoted


(FWIW, test 5, the test that failed, took extra pains
to get working under windows anyway as I needed to
direct output to 'NUL:' under windows instead of '/dev/null'). So I know these paths were not a problem
under earlier versions of perl.

Has something changed?
At the very least, the PERL5LIB paths likely shouldn't
contain a mix of of them, no?

thanks again...

Reply via email to