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 <SYMLINKD> bin [C:\windows\system32\cygwin\bin]
03/05/2015 03:33 PM <SYMLINKD> 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 <SYMLINKD> cygwin [C:\cygwin64]
C:\tmp>dir \windows\syswow64|grep cyg
01/10/2014 01:09 PM <SYMLINKD> 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
