Re: Mixing of forward and back slashes in paths?

On 07/03/2015 06:21, L. Walsh wrote:
> [email protected] 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