Skip Menu |

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

Report information
The Basics
Id: 75077
Status: resolved
Priority: 0/
Queue: File-Temp

People
Owner: Nobody in particular
Requestors: jkeenan [...] cpan.org
Cc: rrt [...] sc3d.org
AdminCc:

Bug Information
Severity: Unimportant
Broken in: 0.22
Fixed in: (no value)



CC: rrt [...] sc3d.org
Subject: unlink0 and unlink1: Clarify their status as utility functions
In this ticket in the Perl 5 RT queue, https://rt.perl.org/rt3/Ticket/Display.html?id=110898, a contributor reported confusion about the documentation of 'unlink1'. The contributor later saw the documentation for unlink1, so the RT ticket was rejected. However, I can see the possibility for confusion. I am providing a patch which should help clarify that unlink1 is a function internal to File::Temp. (Patch has been pulled against cpan/File-Temp/Temp.pm in Perl 5 blead.) Thank you very much. Jim Keenan
Subject: Temp.pm.patch
diff --git a/cpan/File-Temp/Temp.pm b/cpan/File-Temp/Temp.pm index a2d4ae0..7f43db9 100644 --- a/cpan/File-Temp/Temp.pm +++ b/cpan/File-Temp/Temp.pm @@ -27,11 +27,11 @@ C<_can_unlink_opened_file> method should be modified. =item * -Are the return values from C<stat> reliable? By default all the -return values from C<stat> are compared when unlinking a temporary -file using the filename and the handle. Operating systems other than -unix do not always have valid entries in all fields. If C<unlink0> fails -then the C<stat> comparison should be modified accordingly. +Are the return values from C<stat> reliable? By default all the return values +from C<stat> are compared when unlinking a temporary file using the filename +and the handle. Operating systems other than unix do not always have valid +entries in all fields. If utility function C<File::Temp::unlink0> fails then +the C<stat> comparison should be modified accordingly. =item * @@ -1139,10 +1139,10 @@ sub unlink_on_destroy { =item B<DESTROY> -When the object goes out of scope, the destructor is called. This -destructor will attempt to unlink the file (using C<unlink1>) -if the constructor was called with UNLINK set to 1 (the default state -if UNLINK is not specified). +When the object goes out of scope, the destructor is called. This destructor +will attempt to unlink the file (using L<unlink1|"unlink1">) if the +constructor was called with UNLINK set to 1 (the default state if UNLINK is +not specified). No error is given if the unlink fails.
Subject: Re: [rt.cpan.org #75077] unlink0 and unlink1: Clarify their status as utility functions
Date: Thu, 16 Feb 2012 15:43:30 -1000
To: bug-File-Temp [...] rt.cpan.org
From: Tim Jenness <tjenness [...] cpan.org>
Commited to github. On Thu, Feb 16, 2012 at 3:03 PM, James E Keenan via RT <bug-File-Temp@rt.cpan.org> wrote: Show quoted text
> Thu Feb 16 20:03:06 2012: Request 75077 was acted upon. > Transaction: Ticket created by JKEENAN >       Queue: File-Temp >     Subject: unlink0 and unlink1: Clarify their status as utility functions >   Broken in: 0.22 >    Severity: Normal >       Owner: Nobody >  Requestors: jkeenan@cpan.org >      Status: new >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75077 > > > > In this ticket in the Perl 5 RT queue, > https://rt.perl.org/rt3/Ticket/Display.html?id=110898, a contributor > reported confusion about the documentation of 'unlink1'.  The > contributor later saw the documentation for unlink1, so the RT ticket > was rejected. > > However, I can see the possibility for confusion.  I am providing a > patch which should help clarify that unlink1 is a function internal to > File::Temp.  (Patch has been pulled against cpan/File-Temp/Temp.pm in > Perl 5 blead.) > > Thank you very much. > Jim Keenan