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
Re: Mixing of forward and back slashes in paths?
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
Re: Mixing of forward and back slashes in paths?
-Original Message- From: L. Walsh Sent: Saturday, March 07, 2015 5:21 PM To: sisyph...@optusnet.com.au Cc: Strawberry Perl Subject: Re: Mixing of forward and back slashes in paths? 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: The setting of these things are determined by what's in the perl source distro and ought therefore be dealt with at the perl source level - so it needs to be achieved by patching the perl source (and perhaps some of the core modules). I build perl from source myself - and see the same mixture of forward and backward slashes in paths. I don't see it as being Strawberry's responsibility to deal with this (but I have no official position with the Strawberry project). On Windows 7, I strike occasions where forward slashes are unworkable and need to be replaced by backslashes - so I'd be very annoyed if perl were ever to forbid the backslash in a path (or automatically convert it to a forward slash). Here's an example of forward slashes being unworkable on my Windows 7 box. It relies on the existence of ../doc.txt. ### use warnings; use strict; my $f1 = '../doc.txt'; my $f2 = "../doc.txt"; my $f3 = '..\doc.txt'; my $f4 = "..\\doc.txt"; # will fail warn "failed to copy $f1 to dac.txt" if system 'copy', $f1, 'dac.txt'; # will fail warn "failed to copy $f2 to dec.txt" if system 'copy', $f2, 'dec.txt'; # will succeed warn "failed to copy $f3 to dic.txt" if system 'copy', $f3, 'dic.txt'; # will succeed warn "failed to copy $f4 to duc.txt" if system 'copy', $f4, 'duc.txt'; ### I don't know if the behaviour I see from this script is common. Even if perl were to convert the backslash to forward slash for display purposes only, I would be very annoyed. If I were to "say $f1;" in the above script, I would expect to see what's actually there - namely "..\doc.txt". But it's not me you need to convince about this - it's p5p or kmx (who does have an official position with the Strawberry project). I suspect it's now too late for either p5p or kmx to do anything about this for the upcoming 5.22 - maybe take it up in the next round of blead releases (5.23) ? Cheers, Rob
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?
-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 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). If you do: $test = "C:\this"; what do you expect to be output by: printf "%s\n", $test; And if you do: $^X = "C:\Strawberry\perl\bin\perl.exe"; what do you expect to be output by: printf "5.20 path for perl: $^X???\n"; Cheers, Rob
