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 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;\ C:\strawberry\perl\site\bin;C:\strawberry\perl\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 select((select(1),$|=1)[0]); 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??? INC: /Users/law.Bliss/bin/lib S:/Dwimperl/perl/site/lib S:/Dwimperl/perl/vendor/lib S:/Dwimperl/perl/lib . --- 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 strings)? Thanks! (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...
Re: Mixing of forward and back slashes in paths?
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.
Re: Mixing of forward and back slashes in paths?
Rob Dixon wrote: On 07/03/2015 06:21, L. Walsh wrote: - 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. --- It's worked for me since win98 days... This is from cmd.exe: C:\Users\law.Bliss>cmd Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\law>echo %PATH% .;C:/prog64/vim;C:/bin;C:/sbin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\prog\NVIDIA Corporation\PhysX\Common;C:\Prog64\VanDykeSoftware\Clients;C:\prog\sysinternals\cmd;C:\prog\sy sinternals;C:\Prog\QuickTime C:\Users\law.Bliss>gvim C:\Users\law.Bliss>help set Displays, sets, or removes cmd.exe environment variables. SET [variable=[string]] ... C:\Users\law.Bliss>cd /tmp C:\tmp.Bliss> systeminfo Host Name: Athenae OS Name: Microsoft Windows 7 Ultimate OS Version:6.1.7601 Service Pack 1 Build 7601 ... C:\tmp>ls \\ astarte athenae bliss ishtar web-proxy C:\tmp>ls //Bliss/backup Archived_Tmpfiles MSBACKUP MSBACKUP2 athenae.tar.gz etc - This is only cmd.exe -- various utils don't work, but in 'NT', it accepts either. Various (most) win32 utils won't work with '/' as they use it as a switch char, but at the system level it works fine. My cygwin install is "virtually" in my C:/bin folder. (I say virtually, cuz: \\Bliss\law>dir C:\|grep bin 03/21/2014 03:31 AM bin [C:\windows\system32\cygwin\bin] 03/05/2015 03:33 PM sbin [C:\Windows\System32\cygwin\sbin] And the cygwin dirs point to the proper 'bit-size' dirs... C:\tmp>dir \windows\system32|grep cygwin 01/11/2014 09:21 PM cygwin [C:\cygwin64] C:\tmp>dir \windows\syswow64|grep cyg 01/10/2014 01:09 PM cygwin [C:\cygwin] (it does work, but is hard to maintain, since cygwin overwrites the 'symlinks' -- even if they are file-system junctions (a path-based filesystem mount in windows) - 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. My confusion stems from my having tested one of my CPAN modules that uses $^X in double quotes and I got a FAIL report in 5.20.2 strawberry, whereas I got no such error from 5.14 - 5.18. I am confused as to why it worked before but fails now when the module and test have not changed. That's why I'm confused. It's not that it isn't even *trivial* to fix it (1 test, need to move the $^X out of the "" and just prepend it to the cmd to be run), I'm just trying to figure out what could have changed such that it worked in earlier versions of perl but not now in 5.20.2...? Any ideas why it wouldn't have failed before? Appreciate any ideas you might come up with -- I prefer to find out *why* a problem has happened before I apply a fix. Thanks much! Linda
