sisyph...@optusnet.com.au wrote:
-----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
P-1.1.24:
- MSWin32-x86-multi-thread-64int / 5.20.2:
- FAIL
http://www.cpantesters.org/cpan/report/bc273757-6c01-1014-a765-afcf632b568brt
You mean:
http://www.cpantesters.org/cpan/report/bc273757-6c01-1014-a765-afcf632b568b
---
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
perl.
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.
