-----Original Message----- From: L. Walsh
Sent: Saturday, March 07, 2015 5:00 AM
To: Strawberry Perl
Subject: Mixing of forward and back slashes in paths?

I recently was looking into a CPAN tester report

- MSWin32-x86-multi-thread-64int / 5.20.2:

You mean:
I wonder how I messed that up... but yeah.

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

Sorry - I couldn't work out what it is that you're asking about.
And I couldn't spot anything in the testers report that indicates any problem with any of the paths. Both "\" and "/" are acceptable (and essentially equivalent) where used (AFAICS).
Not really. In the past on windows, perl has converted 'backslashes' to forward slashes, because in perl, backslashes are a quote char. As I pointed out in 5.14,
all the paths (that come from perl (@INC, $^X, PERL5LIB) have had forward
slashes used for the path separators so the Windows version would be as compatible as possible with the linux versions. The idea was to to support compatibility.

Now if a *user*, uses '\', then that's on them -- but perl didn't contribute to
the problem.

If you do:
$test = "C:\this";
I wouldn't do that. I'd use $test= "C:/this" because "\" does special things in

what do you expect to be output by:
printf "%s\n", $test;

And if you do:
$^X = "C:\Strawberry\perl\bin\perl.exe";
I don't do it -- perl does it. Look at the listing for PERL5LIB at the bottom of the report:

Built under MSWin32
Compiled at Feb 21 2015 12:36:01
%ENV: PERL5LIB="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"
It has the backslashes in double quotes. How should anyone expect that to work?

what do you expect to be output by:
printf "5.20 path for perl: $^X???\n";
   The same thing that perl 5.20 prints out --
but in 5.14 it prints C:/Strawberry/perl/bin/perl.exe" -- which, if you want the best compatibility in the windows environment for CPAN scripts written mostly against
*nix hosts, would seem to be the wise choice.

That's why I was asking if this incompatibility has been introduced on purpose or if it has slipped by? Having the windows version of perl NOT convert BS's to FS's seem a large break in past compatibility and *needlessly* causes breaking in CPAN modules
that are largely developed in *nix compatible environments.

Reply via email to