The problem stems from the fact that under Win32 you can't delete a file that the OS regards as open. Here is an example.

$file = 'c:\test.txt';
open F, ">$file" or die "Can't open $file $!\n";
# uncomment this to gain permission to unlink $file...
# close F;
unlink $file or die "Can't unlink $file $!\n";
[download]

If you close the filehandle opened on $file you can unlink it, if not you get permission denied. When you run your script with an output redirect to a file the OS filehandle on that file is not closed until the shell has finished running your script, ergo you can't delete that redirect file until your script finishes but you need the script running to do the unlink. Catch 22. Solution: write and delete the file from within your script. This works fine:

$file = "c:\\test.txt";
`dir c: > $file`;
unlink $file or die "Can't unlink $file $!\n";
[download]

I can't see any good reason to do it but you can do this on the command line:

perl somscript.pl > somefile.txt; del somefile.txt
[download]

PS the or $! == 2 makes no sense to me as $! is unlikely to ever contain a string that evals to 2

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

I can't see any good reason to do it but you can do this on the command line

One place where this approach to files and file handles can be used is in the generation of temporary files - As discussed briefly in Using Temporary Files in Perl, where the underlying operating system allows this, temporary files can be unlinked while their file handle is held open. This results in an anonymous STDIO stream, which is excellent for the purposes of scoped temporal storage, side-stepping many of the race issues encountered in temporary file name generation and usage. The only disadvantage from this approach is that the data stored within the STDIO stream can only be accessed through the opened file handle.

This method of temporary file handling is also discussed briefly with reference to Windows systems in the File::Temp documentation.

 

When I said I could not see any good reason to do what seemed to being done I was refering to the external redirect and internal unlinking of the redirect file. I like the IO::File inplementation for temp files myself:

require IO::File; 
$fh = new IO::File->new_tmpfile
[download]

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Well now.

This is what I love about this place. Always something new to learn from the posts.

Never used File::Temp or IO::File for the matter. Makes more sense to use these mods for what I was doing. It also didn't require much change for the code!

Thanks you and ++

It is Windows thing!!!!

I too threw the two lines of code on a unix box. File gets removed! Windows gives you a permissions error!

I will have to sleep on it! Sorry about that!

It's a windows thing!
Yes, indeed. Redirection to a file in unix works like this:
- open output file for truncate (>) or append (>>)
- start all processes involved in the pipeline
- keep data flowing through the pipe to the file till something quits.
In windows/dos, it seems to go something like this:
- run the first process in the pipeline, and put its output somewhere; when it finishes:
- start the next process (if any) and pass it the output created by the previous process
- when the last process is done, write its output to the redirection file.
Maybe windows does something to create the file first (else you'd get a "file not found" error from unlink), but it's protected until the OS is done with it (which is after your process exits).

It did? Well this is the code:

sub mail_results {
    my $file = 'D:\Sysad-perl\scripts\Reports\AntiVirus Status\mailrpt
+.txt';

    if ( -e $file ) {
        #
        # Mail the report.
        my $sender = new Mail::Sender {smtp => 'synplcty.synplicity.co
+m', 
             from => 'mshember@synplicity.com'};
        
                $sender->MailFile({to => 'mshember@synplicity.com',
        subject => 'McAfee AVP Level Report',
        msg => "Here is today's report.",
        file => $file}    );
    }
    unlink $file or $! == 2 or die "Cannot unlink $file: $!";
}
[download]

This is the message

Cannot unlink D:\Sysad-perl\scripts\Reports\AntiVirus Status\mailrpt.t
+xt: Permission denied at D:\Sysad-perl\scripts\Reports\AntiVirus Stat
+us\avpcheck.pl line 3
65.
[download]

I wonder if the fact that it is win32 causing the problem?

I will redo my approach.

Thanks especially to Tachyon and Graff. Makes more sense now!

Oh and Tachyon; the 2 thing was something I read from Merlyn. I will change it! ;-)

Sorry, but your question makes no sense. Maybe you should get some sleep and ask again?

The biggest point: Doesn't matter what the file name is, if you created it, you can remove it. If you can shove it into a Perl variable, call unlink on it.

*Grins* You are probably right. I stuck some code in the post above

I thought there was no reason it should work but for some reason it don't.