FAQ
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...

Search Discussions

  • Sisyphus1 at Mar 7, 2015 at 12:52 am
    -----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
  • L. Walsh at Mar 7, 2015 at 6:21 am

    sisyphus1@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.
  • Sisyphus1 at Mar 8, 2015 at 8:30 am
    -----Original Message-----
    From: L. Walsh
    Sent: Saturday, March 07, 2015 5:21 PM
    To: sisyphus1@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
  • Rob Dixon at Mar 8, 2015 at 2:47 pm

    On 07/03/2015 06:21, L. Walsh wrote:
    sisyphus1@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
  • L. Walsh at Mar 9, 2015 at 7:38 am

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupwin32-vanilla @
categoriesperl
postedMar 6, '15 at 6:00p
activeMar 9, '15 at 7:38a
posts6
users3
websitestrawberryperl.com

3 users in discussion

L. Walsh: 3 posts Sisyphus1: 2 posts Rob Dixon: 1 post

People

Translate

site design / logo © 2019 Grokbase