On 07/03/2015 06:21, L. Walsh wrote:
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-afcf632b568b
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
(andessentially 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. Theidea 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.
I'm not clear exactly what "incompatability* you're referring to, but
you clearly have some misconceptions.
- Perl has never converted backslashes to forward slashes. It simply
accepts *either* form of slash as path separators in parameters to IO
operators like mkdir, opendir, open, chdir etc. That is primarily to
avoid having to escape (with a second backslash) all of the backslash
separators in a canonical Windows path
- The line
PERL5LIB="C:\cpan\build\Types-Core-0.1.4-8EUNyT/blib ...
arch;C:\cpan\build\mem-0.4.5-dZP9Gl/blib/lib"
is in *shell* context, and the list is in double quotes to allow for
spaces in any of the path components. If you used the same expression
inside Perl then you wouldn't get the same string, but that is irrelevant
- The PATH environment variable *cannot* use forward slashes as path
separators. It is purely for Windows' purposes, and forward slash is an
illegal character in a Windows path string.
- The issue with backslashes only affects string constants. "C:/this" is
fine because forward slashes aren't special, but "C:\this" won't work
because \t is interpreted as a horizontal tab character within double
quotes. But you can write "C:\\this" or 'C:\this', and they will work
fine when used as IO operator parameters
As I said, I'm not clear where your confusion lies, but I hope this
helps to clear things up.
Rob
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
