Marza has asked for the wisdom of the Perl Monks concerning the following question:

I am probably being stupid but I am working with no sleep...

Is it even possible to unlink a file that was created with the '>' sign?


perl > output.txt mails a file and then tries:

my $file = "output.txt"; unlink $file;

For the heck of it; I tried close STDOUT but still got the error

Replies are listed 'Best First'.
Re: Unlink Permission Denied
by tachyon (Chancellor) on May 03, 2002 at 04:09 UTC

    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";

    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";

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

    perl > somefile.txt; del somefile.txt

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




      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




        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 ++

Re: Unlink Permission Denied
by Marza (Vicar) on May 03, 2002 at 02:49 UTC

    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).
Re: Unlink Permission Denied
by emilford (Friar) on May 03, 2002 at 02:15 UTC
    I'm not sure why those two lines of code don't work for you. I tossed them into a script and it removed the "output.txt" file just fine. Perhaps something before you attempt to unlink the file is causing you problems? What error are you getting from this? That might be helpful for us to know as well.
      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 => ' +m', from => ''}; $sender->MailFile({to => '', subject => 'McAfee AVP Level Report', msg => "Here is today's report.", file => $file} ); } unlink $file or $! == 2 or die "Cannot unlink $file: $!"; }

      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\ line 3 65.

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

Thanks everybody!
by Marza (Vicar) on May 03, 2002 at 04:33 UTC

    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! ;-)

Re: Unlink Permission Denied
by VSarkiss (Monsignor) on May 03, 2002 at 02:25 UTC

    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.