Skip Menu |

This queue is for tickets about the Regexp-Log CPAN distribution.

Report information
The Basics
Id: 1971
Status: resolved
Worked: 1 min
Priority: 0/
Queue: Regexp-Log

People
Owner: book [...] cpan.org
Requestors: corion [...] cpan.org
Cc:
AdminCc:

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



Subject: Test 20debug.t fails under Win32 because it can't remove the temp file
Test file 20debug.t dies under Win32, because it can't unlink the file at the end. All tests pass. Changing the "die" to a "diag" makes the test survive, the remaining temp file can be removed manually. unlink $file or diag "Could not remove $file: $!"; Personally, I would use File::Temp for temp files, but that's just me :-)
Of course, I forgot my Perl information : D:\.cpan\build\Regexp-Log-BlueCoat-0.02>perl -V Summary of my perl5 (revision 5 version 6 subversion 1) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultiplicity=def ine useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cl', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE - DNO_STRICT - DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS - DPERL_MSVCRT_READ FIX', optimize='-O1 -MD -DNDEBUG', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize =4 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='', ldflags ='-nologo -nodefaultlib -release - libpath:"f:\dev\dp\perl-5. 6_install\lib\CORE" -machine:x86' libpth=\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32 .lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsoc k32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comd lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release - libpath:"f: \dev\dp\perl-5.6_install\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEXT PERL_IMP LICIT_SYS Locally applied patches: IndigoPerl Build 626 Built under MSWin32 Compiled at May 6 2001 21:37:25 @INC: D:/Programme/indigoperl-5.6/lib D:/Programme/indigoperl-5.6/site/lib .
[CORION - Tue Jan 21 18:34:45 2003]: Show quoted text
> Test file 20debug.t dies under Win32, because it can't unlink the file > at the end. All tests pass. Changing the "die" to a "diag" makes the > test survive, the remaining temp file can be removed manually. > > unlink $file or diag "Could not remove $file: $!"; > > Personally, I would use File::Temp for temp files, but that's just me > :-)
In fact, I think it dies under Win32 because the system won't let one remove an open file. Which $file is, since it's in @ARGV and read through <>. So I added a close ARGV before the unlink line: --- t/20debug.t 20 Jan 2003 09:12:45 -0000 1.2 +++ t/20debug.t 10 Mar 2003 16:00:02 -0000 @@ -42,6 +42,7 @@ ok( <> eq "a b cs cn c d \n", "Debug for a match" ); ok( <> eq "a a \n", "Debug for non-match" ); ok( <> eq "a b cs cn c d ", "Debug for a match" ); +close ARGV; # cleanup files -unlink $file or die "Could not remove $file: $!"; +unlink $file or diag "Could not remove $file: $!"; Could you try this, and tell me if I can close the bug? Thanks.
[BOOK - Mon Mar 10 11:01:18 2003]: Show quoted text
> ... > Could you try this, and tell me if I can close the bug? > Thanks.
Yes, it works, the bug can be closed. (I tried to do this already via email to rt, but that seems to be broken ...)