Skip Menu |

This queue is for tickets about the File-Path CPAN distribution.

Report information
The Basics
Id: 121102
Status: resolved
Priority: 0/
Queue: File-Path

People
Owner: jkeenan [...] cpan.org
Requestors: itcharlie [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in:
  • 2.13
  • 2.14



Subject: File::Path v2.12_003 Build Error on Windows 10 Perl 5.24.1using Cpanm
Date: Thu, 13 Apr 2017 13:20:33 -0400
To: bug-File-Path [...] rt.cpan.org
From: Charlie Gonzalez <itcharlie [...] gmail.com>
Example output from Powershell ++++++++ PS C:\Users\cgonzalez\Desktop> cpanm -L .\install_FilePath\ http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Pat h-2.12_003.tar.gz --> Working on http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Path-2.12_003.tar.gz Fetching http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Path-2.12_003.tar.gz ... OK Configuring File-Path-2.12_003 ... OK Building and testing File-Path-2.12_003 ... FAIL ! Installing http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Path-2.12_003.tar.gz failed. See C:\Users\CGONZA~1 \.cpanm\work\1492012127.10104\build.log for details. Retry with --force to force install it. PS C:\Users\cgonzalez\Desktop> ++++++++ Attached is the build error log file. Charlie Gonzalez (E) itcharlie@gmail.com Github Profile <https://github.com/itcharlie>

Message body is not shown because sender requested not to inline it.

On Thu Apr 13 13:20:51 2017, itcharlie wrote: Show quoted text
> Example output from Powershell > > > ++++++++ > PS C:\Users\cgonzalez\Desktop> cpanm -L .\install_FilePath\ > http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Pat > h-2.12_003.tar.gz > --> Working on > http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Path- > 2.12_003.tar.gz > Fetching > http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Path- > 2.12_003.tar.gz > ... OK > Configuring File-Path-2.12_003 ... OK > Building and testing File-Path-2.12_003 ... FAIL > ! Installing > http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Path- > 2.12_003.tar.gz > failed. See C:\Users\CGONZA~1 > \.cpanm\work\1492012127.10104\build.log for details. Retry with > --force to > force install it. > PS C:\Users\cgonzalez\Desktop> > ++++++++ > > Attached is the build error log file. > > > Charlie Gonzalez > (E) itcharlie@gmail.com > Github Profile <https://github.com/itcharlie>
Charlie, thanks very much for filing this report. When I first saw this the other day, I saw 'getpwnam' and thought, "Oh, I used that in some tests I recently added. That's probably where the problem is." It turns out that there are quite a few Perl built-in functions that are not implemented in Windows. See 'perldoc perlport'. So in my 'functions-not-available-on-Windows' branch I reworked the tests by placing those which used Unix-only functions in SKIP blocks. All tests PASSed. However, when you told me today that you were still having 'getpwnam' cited in a failure report, I was really surprised. It was only at that point that I realized we were invoking 'getpwnam' and 'getgrnam' in lib/File/Path.pm. But I didn't add them there. They were added in the work we did after the 2015 NYC Perl Hackathon and have been present since CPAN release 2.11. ##### $ git checkout 2.11 Previous HEAD position was 2f6b8cb... version bump 2.08_01 => 2.09, add Github repo links HEAD is now at 3e5e3b6... Release version bump, change arg checking from croak to carp, remove tests accordingly, change skip and total test counts, edit release Changes accordingly [File-Path] 544 $ ack 'get((pw|gr)nam|pwuid|grgid)' lib t lib/File/Path.pm 123: my $uid = ( getpwnam $arg->{owner} )[2]; 135: my $gid = ( getgrnam $arg->{group} )[2]; 1044:directories to the symbolic name [owner], but C<getpwnam> did 1051:directories to the symbolic name [group], but C<getgrnam> did t/Path.t 617: do { ++$max_user } while (getpwnam($max_user)); 618: do { ++$max_group } while (getgrnam($max_group)); ##### But -- and here's the shocker -- until this past month we never had any smoke test failures reported on Win32 due to use of non-Windows functions in the source code. See, e.g., http://matrix.cpantesters.org/?dist=File-Path%202.11;os=mswin32;reports=1; all green! So this will need further investigation. Thank you very much. Jim Keenan
On Thu Apr 13 14:41:12 2017, JKEENAN wrote: Show quoted text
> On Thu Apr 13 13:20:51 2017, itcharlie wrote:
> > Example output from Powershell > > > > > > ++++++++ > > PS C:\Users\cgonzalez\Desktop> cpanm -L .\install_FilePath\ > > http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Pat > > h-2.12_003.tar.gz > > --> Working on > > http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Path- > > 2.12_003.tar.gz > > Fetching > > http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Path- > > 2.12_003.tar.gz > > ... OK > > Configuring File-Path-2.12_003 ... OK > > Building and testing File-Path-2.12_003 ... FAIL > > ! Installing > > http://search.cpan.org/CPAN/authors/id/J/JK/JKEENAN/File-Path- > > 2.12_003.tar.gz > > failed. See C:\Users\CGONZA~1 > > \.cpanm\work\1492012127.10104\build.log for details. Retry with > > --force to > > force install it. > > PS C:\Users\cgonzalez\Desktop> > > ++++++++ > > > > Attached is the build error log file. > > > > > > Charlie Gonzalez > > (E) itcharlie@gmail.com > > Github Profile <https://github.com/itcharlie>
> > Charlie, thanks very much for filing this report. > > When I first saw this the other day, I saw 'getpwnam' and thought, > "Oh, I used that in some tests I recently added. That's probably > where the problem is." > > It turns out that there are quite a few Perl built-in functions that > are not implemented in Windows. See 'perldoc perlport'. > > So in my 'functions-not-available-on-Windows' branch I reworked the > tests by placing those which used Unix-only functions in SKIP blocks. > All tests PASSed. > > However, when you told me today that you were still having 'getpwnam' > cited in a failure report, I was really surprised. It was only at > that point that I realized we were invoking 'getpwnam' and 'getgrnam' > in lib/File/Path.pm. But I didn't add them there. They were added in > the work we did after the 2015 NYC Perl Hackathon and have been > present since CPAN release 2.11. >
In fact, getpwnam and getgrnam were present in Path.pm -- the predecessor to lib/File/Path.pm -- long before the current maintainers took over. They have been present at least since 2009. Here is the earliest commit I have (so far) found which have these functions in Path.pm.: ##### commit ea4d91678a8963ce75495ca96679301962030e0a Author: David Landgren <david@landgren.net> Date: Sun Oct 4 02:31:05 2009 -0800 ##### [snip] Show quoted text
> > So this will need further investigation. > > Thank you very much. > Jim Keenan
For reference, am attaching tarball of the most recent version which I asked Charlie Gonzalez to test. This is equivalent to the 'functions-not-available-on-windows' branch on github at commit cc7e62208eabdd8597823024b7649d0c0981986f.
Subject: File-Path-2.12_004.tar.gz
Download File-Path-2.12_004.tar.gz
application/gzip 28.9k

Message body not shown because it is not plain text.

On Thu Apr 13 16:10:32 2017, JKEENAN wrote: Show quoted text
> For reference, am attaching tarball of the most recent version which I > asked Charlie Gonzalez to test. This is equivalent to the 'functions- > not-available-on-windows' branch on github at commit > cc7e62208eabdd8597823024b7649d0c0981986f.
So I now have a hypothesis on what is happening. While working on 2.12_003 and _004, I was trying to boost the extent to which t/*.t exercises the File-Path source code under lib/. In other words, I was trying to boost the coverage ratio. I know that I did boost coverage by a lot. That was accomplished by adding more tests for every nook and cranny under mkpath(), rmtree(), etc. But in the process of so doing, I probably added tests for combinations of arguments which are implausible on Windows. Note that in master, the points at which we call getpwnam() and getgrnam() are these: ##### sub mkpath { my $old_style = !( @_ and __is_arg( $_[-1] ) ); my $data; my $paths; if ($old_style) { my ( $verbose, $mode ); ( $paths, $verbose, $mode ) = @_; $paths = [$paths] unless UNIVERSAL::isa( $paths, 'ARRAY' ); $data->{verbose} = $verbose; $data->{mode} = defined $mode ? $mode : oct '777'; } else { my %args_permitted = map { $_ => 1 } ( qw| chmod error group mask mode owner uid user verbose | ); ... $data->{owner} = delete $data->{user} if exists $data->{user}; $data->{owner} = delete $data->{uid} if exists $data->{uid}; if ( exists $data->{owner} and $data->{owner} =~ /\D/ ) { my $uid = ( getpwnam $data->{owner} )[2]; if ( defined $uid ) { $data->{owner} = $uid; } else { _error( $data, "unable to map $data->{owner} to a uid, ownership not changed" ); delete $data->{owner}; } } if ( exists $data->{group} and $data->{group} =~ /\D/ ) { my $gid = ( getgrnam $data->{group} )[2]; if ( defined $gid ) { $data->{group} = $gid; } else { _error( $data, "unable to map $data->{group} to a gid, group ownership not changed" ); delete $data->{group}; } } ... } } ##### So getpwnam() is only encountered if $data{owner} exists and is a non-numeric string. Similarly, getgrnam() is only encountered if $data{group} exists and is a non-numeric string. If these conditions do not obtain, then Perl never has to ask, "Are getpwnam() and/or getgrnam() implemented on this system?" And if on Windows no one would ever pass 'owner', 'user', 'uid' or 'group' in the hashref which is the optional final argument to make_path(), then no user on Windows would ever encounter this error. The only time these built-in functions would be encountered in the not-so-real-world of testing would be in t/Path.t. So, Charlie, can you run the following command from the latest tarball that I sent you and post the output? ##### prove -vb t/Path.t 1>t_Path_t_output.txt 2>&1 ##### That way, I'll be able to see the exact test at which we're getting the fatal error. Thank you very much. Jim Keenan
Subject: Re: [rt.cpan.org #121102] File::Path v2.12_003 Build Error on Windows 10 Perl 5.24.1 using cpanm
Date: Thu, 13 Apr 2017 23:52:33 -0400
To: bug-File-Path [...] rt.cpan.org
From: Charlie Gonzalez <itcharlie [...] gmail.com>
Ran the command as suggested. Results attached. Charlie Gonzalez (E) itcharlie@gmail.com Github Profile <https://github.com/itcharlie> On Thu, Apr 13, 2017 at 4:26 PM, James E Keenan via RT < bug-File-Path@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=121102 > > > On Thu Apr 13 16:10:32 2017, JKEENAN wrote:
> > For reference, am attaching tarball of the most recent version which I > > asked Charlie Gonzalez to test. This is equivalent to the 'functions- > > not-available-on-windows' branch on github at commit > > cc7e62208eabdd8597823024b7649d0c0981986f.
> > So I now have a hypothesis on what is happening. While working on > 2.12_003 and _004, I was trying to boost the extent to which t/*.t > exercises the File-Path source code under lib/. In other words, I was > trying to boost the coverage ratio. I know that I did boost coverage by a > lot. That was accomplished by adding more tests for every nook and cranny > under mkpath(), rmtree(), etc. > > But in the process of so doing, I probably added tests for combinations of > arguments which are implausible on Windows. Note that in master, the > points at which we call getpwnam() and getgrnam() are these: > > ##### > sub mkpath { > my $old_style = !( @_ and __is_arg( $_[-1] ) ); > > my $data; > my $paths; > > if ($old_style) { > my ( $verbose, $mode ); > ( $paths, $verbose, $mode ) = @_; > $paths = [$paths] unless UNIVERSAL::isa( $paths, 'ARRAY' ); > $data->{verbose} = $verbose; > $data->{mode} = defined $mode ? $mode : oct '777'; > } > else { > my %args_permitted = map { $_ => 1 } ( qw| > chmod > error > group > mask > mode > owner > uid > user > verbose > | ); > ... > $data->{owner} = delete $data->{user} if exists $data->{user}; > $data->{owner} = delete $data->{uid} if exists $data->{uid}; > if ( exists $data->{owner} and $data->{owner} =~ /\D/ ) { > my $uid = ( getpwnam $data->{owner} )[2]; > if ( defined $uid ) { > $data->{owner} = $uid; > } > else { > _error( $data, > "unable to map $data->{owner} to a uid, ownership > not changed" > ); > delete $data->{owner}; > } > } > if ( exists $data->{group} and $data->{group} =~ /\D/ ) { > my $gid = ( getgrnam $data->{group} )[2]; > if ( defined $gid ) { > $data->{group} = $gid; > } > else { > _error( $data, > "unable to map $data->{group} to a gid, group > ownership not changed" > ); > delete $data->{group}; > } > } > ... > } > } > ##### > > So getpwnam() is only encountered if $data{owner} exists and is a > non-numeric string. Similarly, getgrnam() is only encountered if > $data{group} exists and is a non-numeric string. If these conditions do > not obtain, then Perl never has to ask, "Are getpwnam() and/or getgrnam() > implemented on this system?" And if on Windows no one would ever pass > 'owner', 'user', 'uid' or 'group' in the hashref which is the optional > final argument to make_path(), then no user on Windows would ever encounter > this error. The only time these built-in functions would be encountered in > the not-so-real-world of testing would be in t/Path.t. > > So, Charlie, can you run the following command from the latest tarball > that I sent you and post the output? > > ##### > prove -vb t/Path.t 1>t_Path_t_output.txt 2>&1 > ##### > > That way, I'll be able to see the exact test at which we're getting the > fatal error. > > Thank you very much. > Jim Keenan > > >
prove : The getpwnam function is unimplemented at C:\Users\cgonzalez\.cpanm\work\1492103902.6672\File-Path-2.12_004\blib\lib/File/Path.pm line 128. At line:1 char:1 + prove -vb t/Path.t 1>t_Path_t_output.txt 2>&1 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (The getpwnam fu...th.pm line 128.:String) [], RemoteException + FullyQualifiedErrorId : NativeCommandError # Looks like your test exited with 2 just after 143. t/Path.t .. 1..168 ok 1 - use Cwd; ok 2 - use File::Path; ok 3 - use File::Spec::Functions; ok 4 - mkdir parent dir 0111 ok 5 - mkdir child dir 0111 ok 6 - mhx does not exist 0111 ok 7 - mkdir parent dir 0777 ok 8 - mkdir child dir 0777 ok 9 - mhx does not exist 0777 ok 10 - created list of directories ok 11 - skipped making existing directory ok 12 - rmtree'ed a file ok 13 - Can't create a directory named '' ok 14 - baseline 3 ok 15 - first after 3 ok 16 - second after 4 ok 17 - ARGV 3 ok 18 - third after 3 ok 19 - fourth after 4 ok 20 - ancestor error ok 21 - ancestor named ok 22 - ancestor reason ok 23 - child not removed ok 24 - ancestor not removed ok 25 - ancestor now removed ok 26 - rmtree of nothing, count of zero ok 27 - no diagnostic captured ok 28 - skipped making existing directories (old style 1) ok 29 - created directory (new style 1) ok 30 - created directory (new style 1) cross-check ok 31 - skipped making existing directories (old style 2) ok 32 - created directory (new style 2) ok 33 - created directory (new style 2) cross-check ok 34 - removed directory unsafe mode ok 35 - removed directory safe mode ok 36 - made one or more dirs because of .. ok 37 - made less than two dirs because of .. ok 38 - directory after parent ok 39 - nothing created ok 40 - no errors unlinking a and z ok 41 - list contains 4 elements ok 42 - dir a still exists ok 43 - dir z still exists ok 44 - created directory (old style 2 verbose undef) ok 45 - created directory (old style 2 verbose undef) cross-check ok 46 - removed directory 2 verbose undef ok 47 - created directory (old style 2a verbose undef) ok 48 - created directory (old style 2a verbose undef) cross-check ok 49 - removed directory 2a verbose undef ok 50 - created directory (old style 3 mode undef) ok 51 - created directory (old style 3 mode undef) cross-check ok 52 - removed directory 3 verbose undef ok 53 - created write-only dir ok 54 - created write-only directory cross-check ok 55 - removed write-only dir ok 56 - chdir to temp dir ok 57 - new-style 3 dirs created ok 58 - new-style 3 dirs removed ok 59 - new-style 3 dirs created (redux) ok 60 - new-style 3 dirs removed (redux) ok 61 - new-style 2 dirs created ok 62 - new-style 2 dirs removed ok 63 # skip MSWin32 doesn't allow newline in paths ok 64 # skip MSWin32 doesn't allow newline in paths ok 65 - chdir parent ok 66 # skip Don't need Force_Writeable semantics on MSWin32 ok 67 # skip Don't need Force_Writeable semantics on MSWin32 ok 68 # skip Don't need Force_Writeable semantics on MSWin32 ok 69 # skip Don't need Force_Writeable semantics on MSWin32 ok 70 # skip Don't need Force_Writeable semantics on MSWin32 ok 71 # skip Don't need Force_Writeable semantics on MSWin32 ok 72 - file exists in place of directory ok 73 - caught error condition ok 74 - and the message is: File exists; Cannot create a file when that file already exists ok 75 - no directory created (old-style) err=mkdir test-58f046e0-2258-18048\file: File exists; Cannot create a file when that file already exists at t/Path.t line 460. ok 76 - create a ZZ directory ok 77 - blow it away via @ARGV ok 78 # skip Windows chmod test skipped ok 79 # skip Windows chmod test skipped ok 80 # skip Windows chmod test skipped ok 81 # skip Windows chmod test skipped ok 82 # skip Windows chmod test skipped ok 83 # skip Windows chmod test skipped ok 84 # skip Windows chmod test skipped ok 85 # skip Windows chmod test skipped ok 86 # skip Windows chmod test skipped ok 87 # skip Windows chmod test skipped ok 88 # skip Windows chmod test skipped ok 89 # skip Windows chmod test skipped ok 90 # skip Windows chmod test skipped ok 91 # skip Windows chmod test skipped ok 92 # skip Windows chmod test skipped ok 93 # skip Windows chmod test skipped ok 94 # skip Windows chmod test skipped ok 95 # skip Windows chmod test skipped ok 96 # skip Windows chmod test skipped ok 97 - mkpath verbose (old style 1) ok 98 - mkpath verbose (old style 2) ok 99 - rmtree verbose (old style) ok 100 - mkpath verbose (new style 1) ok 101 - mkpath verbose (new style 2) ok 102 - again: rmtree verbose (old style) ok 103 - make_path verbose with final hashref ok 104 - remove_tree verbose with final hashref ok 105 - 2 directories created ok 106 - file created in directory ok 107 - rmtree safe verbose (new style) ok 108 - make_path with final hashref warned due to unrecognized options ok 109 - remove_tree with final hashref failed due to unrecognized options ok 110 - received a final list of results ok 111 - test base directory gone ok 112 - make x8792x ok 113 - ... and chdir x8792x ok 114 - create and delete directory 2.07 ok 115 - .. rmtree fails in File-Path-2.07 ok 116 - Windows path unixified as expected ok 117 - no $arg->{error}: defined 2nd and 3rd args: got expected error message ok 118 - no $arg->{error}: defined 2nd arg; undefined 3rd arg: got expected error message ok 119 - first element of array inside $error is hashref ok 120 - key of hash is empty string, since 3rd arg was undef ok 121 - value of hash is 2nd arg: message in a bottle ok 122 - first element of array inside $second_error is hashref ok 123 - key of hash is '/path/to/glory', since 3rd arg was defined ok 124 - value of hash is 2nd arg: ok 125 - first element of array inside $third_error is hashref ok 126 - key of hash is empty string, since 3rd arg was undef ok 127 - value of hash is 2nd arg: # https://rt.cpan.org/Ticket/Display.html?id=117019 ok 128 - Created 3 subdirectories ok 129 - directory 'C:\Users\CGONZA~1\AppData\Local\Temp\a\b\c' removed, as expected ok 130 - CPAN 117019: No warning thrown when re-using $opts ok 131 - directory 'C:\Users\CGONZA~1\AppData\Local\Temp\a\b' removed, as expected ok 132 - CPAN 117019: No warning thrown when re-using $opts ok 133 - directory 'C:\Users\CGONZA~1\AppData\Local\Temp\a' removed, as expected ok 134 - If not provided with any paths, remove_tree() will return a count of 0 things deleted ok 135 - If not provided with any paths, remove_tree() will return a count of 0 things deleted ok 136 - Got expected carp ok 137 - If not provided with any paths, remove_tree() will return a count of 0 things deleted ok 138 - Got expected carp ok 139 - If provided only with an undefined value, remove_tree() will return a count of 0 things deleted ok 140 - Got expected carp ok 141 - If provided with an empty string for a path, remove_tree() will return a count of 0 things deleted ok 142 - If not provided with any paths, make_path() will return a count of 0 things created ok 143 - If not provided with any paths, make_path() will return a count of 0 things created Dubious, test returned 2 (wstat 512, 0x200) Failed 25/168 subtests (less 27 skipped subtests: 116 okay) Test Summary Report ------------------- t/Path.t (Wstat: 512 Tests: 143 Failed: 0) Non-zero exit status: 2 Parse errors: Bad plan. You planned 168 tests but ran 143. Files=1, Tests=143, 1 wallclock secs ( 0.06 usr + 0.02 sys = 0.08 CPU) Result: FAIL
On Thu Apr 13 23:52:58 2017, itcharlie wrote: Show quoted text
> Ran the command as suggested. Results attached. >
Thanks for that output. To further explore this hypothesis, here's what I would like you to do on your Windows machine. 1. git clone https://github.com/jkeenan/File-Path/tree/master We're going to work in two different branches. 2. git checkout rt-121102-functions-not-available-on-windows perl Makefile.PL make make test # If any test fails, run: prove -vb t/*.t # and send output # In any case, run and send output from: prove -vb t/Path_win32.t 3. git clean -dfx git checkout research-earliest-getpwnam-getgrnam perl Makefile.PL make make test # Run and send output from: prove -vb t/win32.t Roughly speaking, this is what I'm exploring: Step 3 asks: What if back in 2009 we had written explicit tests to see what happens when you provide a 'group' or 'owner' argument to mkpath() on Win32? Step 2 modifies the source code to warn if you attempt to do that today and adds tests to see if that warning is captured. Thank you very much. Jim Keenan
On Thu Apr 13 23:52:58 2017, itcharlie wrote: Show quoted text
> Ran the command as suggested. Results attached. > > Charlie Gonzalez > (E) itcharlie@gmail.com > Github Profile <https://github.com/itcharlie> > >
CPANtesters is, at long last, starting to catch up. Here is a FAIL report from April 07 which reports the same exception which Charlie reported: http://www.cpantesters.org/cpan/report/a22af1ad-6bf5-1014-bd03-a578ef0376f0 So, working with Charlie to get this fixed on Windows should get this fixed, period. Thank you very much. Jim Keenan
On Fri Apr 14 12:44:45 2017, JKEENAN wrote: I have uploaded File-Path-2.12_004.tar.gz to CPAN. Let's see what CPANtesters on Win32 have to say about this version.
On Tue Apr 18 14:39:21 2017, JKEENAN wrote: Show quoted text
> On Fri Apr 14 12:44:45 2017, JKEENAN wrote: > > I have uploaded File-Path-2.12_004.tar.gz to CPAN. Let's see what > CPANtesters on Win32 have to say about this version.
The Win32 CPANtesters reports for versions 2.12_005 thru 2.12_008 were all PASS. File-Path version 2.13 was released to CPAN today. Charlie: Can you give File-Path 2.13 a spin with 'cpanm' and let us know if everything is okay? Thank you very much. Jim Keenan
Subject: Re: [rt.cpan.org #121102] File::Path v2.12_003 Build Error on Windows 10 Perl 5.24.1 using cpanm
Date: Wed, 31 May 2017 21:49:09 -0400
To: bug-File-Path [...] rt.cpan.org
From: Charlie Gonzalez <itcharlie [...] gmail.com>
Installed it without any issues: PS C:\Users\cgonzalez\Desktop> cpanm -L .\FilePath_2.13 https://cpan.metacpan.org/authors/id/J/JK/JKEENAN/File-Path-2.1 3.tar.gz --> Working on https://cpan.metacpan.org/authors/id/J/JK/JKEENAN/File-Path-2.13.tar.gz Fetching https://cpan.metacpan.org/authors/id/J/JK/JKEENAN/File-Path-2.13.tar.gz ... OK Configuring File-Path-2.13 ... OK Building and testing File-Path-2.13 ... OK Successfully installed File-Path-2.13 1 distribution installed Charlie Gonzalez (E) itcharlie@gmail.com Github Profile <https://github.com/itcharlie> On Wed, May 31, 2017 at 8:58 PM, James E Keenan via RT < bug-File-Path@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=121102 > > > On Tue Apr 18 14:39:21 2017, JKEENAN wrote:
> > On Fri Apr 14 12:44:45 2017, JKEENAN wrote: > > > > I have uploaded File-Path-2.12_004.tar.gz to CPAN. Let's see what > > CPANtesters on Win32 have to say about this version.
> > The Win32 CPANtesters reports for versions 2.12_005 thru 2.12_008 were all > PASS. File-Path version 2.13 was released to CPAN today. > > Charlie: Can you give File-Path 2.13 a spin with 'cpanm' and let us know > if everything is okay? > > Thank you very much. > Jim Keenan > > > >
On Wed May 31 21:49:44 2017, itcharlie wrote: Show quoted text
> Installed it without any issues: > > PS C:\Users\cgonzalez\Desktop> cpanm -L .\FilePath_2.13 > https://cpan.metacpan.org/authors/id/J/JK/JKEENAN/File-Path-2.1 > 3.tar.gz > --> Working on > https://cpan.metacpan.org/authors/id/J/JK/JKEENAN/File-Path-2.13.tar.gz > Fetching > https://cpan.metacpan.org/authors/id/J/JK/JKEENAN/File-Path-2.13.tar.gz ... > OK > Configuring File-Path-2.13 ... OK > Building and testing File-Path-2.13 ... OK > Successfully installed File-Path-2.13 > 1 distribution installed > > > Charlie Gonzalez > (E) itcharlie@gmail.com > Github Profile <https://github.com/itcharlie> > > > On Wed, May 31, 2017 at 8:58 PM, James E Keenan via RT < > bug-File-Path@rt.cpan.org> wrote: >
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=121102 > > > > > On Tue Apr 18 14:39:21 2017, JKEENAN wrote:
> > > On Fri Apr 14 12:44:45 2017, JKEENAN wrote: > > > > > > I have uploaded File-Path-2.12_004.tar.gz to CPAN. Let's see what > > > CPANtesters on Win32 have to say about this version.
> > > > The Win32 CPANtesters reports for versions 2.12_005 thru 2.12_008 were all > > PASS. File-Path version 2.13 was released to CPAN today. > > > > Charlie: Can you give File-Path 2.13 a spin with 'cpanm' and let us know > > if everything is okay? > > > > Thank you very much. > > Jim Keenan > > > > > > > >
File-Path 2.13 and File-Path 2.14 are all PASS on CPANtesters. http://matrix.cpantesters.org/?dist=File-Path%202.13;os=mswin32;reports=1 http://fast-matrix.cpantesters.org/?dist=File-Path%202.14;os=mswin32;reports=1 So I'm marking this ticket Resolved. Thank you very much. Jim Keenan