[cupidvogel]

Hi,this is a generic code I have written to practice with different ways of creating temporary files:

use POSIX qw (tmpnam);
use Fcntl;
use IO::File;
do { $f = tmpnam() } until $fh = IO::File->new($f, O_RDWR | O_CREAT | O_EXCL );
print $f;
print $f "$_\n" while $_++ < 10;
seek($f,0,0);
print <$f>;
print "No\n" if (!(-e "foobar.txt"));
print "Yes\n" if -e $f;
END { unlink $f; print "No\n" if (!(-e $f)); }

Line 5 is supposed to print out the temporary file name, it does, somewhat cryptic names like \s2mg, \s2q0 on Windows. The next line is supposed to print the numbers 0 to 9 in that file. Maybe it does, maybe it doesn't, for when I try to print out its contents after two lines, nothing gets printed out. The next line is just a dummy statement, checking whether all is well. The next line checks the existence of the temporary file, it prints out Yes, confirming that the file has indeed been created. However in the END block, even after I have unlinked the temporary file, no No is printed out. Can somebody explain why the file contents and No aren't printed out? Plus another question, I can read from and write to only text files, right? So if the filename is like \s2mg, it means it isn't a text file, how come can I write something to it?

[dsherohman]

cupidvogel, on 04 April 2012 - 08:56 PM, said:

Line 5 is supposed to print out the temporary file name, it does, somewhat cryptic names like \s2mg, \s2q0 on Windows.

That doesn't seem right... Windows uses \ as a directory separator in paths, so it shouldn't be usable in filenames (and, even if it is, you're only creating pain for yourself if you do use it in filenames). Even in other OSes, \ is special and should probably be avoided in filenames.

cupidvogel, on 04 April 2012 - 08:56 PM, said:

The next line is supposed to print the numbers 0 to 9 in that file. Maybe it does, maybe it doesn't, for when I try to print out its contents after two lines, nothing gets printed out.

Have I mentioned recently that you should use warnings;, especially when trying to figure out odd behavior? Lines 7 and 8 are simply wrong - you're trying to seek and print from $f, which holds the name of the file. The file handle itself is in $fh. If you had turned warnings on, line 7 would have issued the warning "seek() on unopened filehandle".

cupidvogel, on 04 April 2012 - 08:56 PM, said:

However in the END block, even after I have unlinked the temporary file, no No is printed out.

You don't know whether the unlink succeeded or failed because you don't check the return value. Either use autodie; (which will cause your program to automatically die with an appropriate error message if any I/O operations fail) or check the return value of unlink and report the error if it fails (unlink $f or die "unlink failed: $!";).

As for why it would fail, Windows has relatively strict file locking rules and won't let you delete a file while another process has it open. I suspect that this also applies if the same process has it open, but can't readily test it (I'm not in Windows). If this is the cause of the problem, try closing the file before attempting to unlink it.

cupidvogel, on 04 April 2012 - 08:56 PM, said:

I can read from and write to only text files, right? So if the filename is like \s2mg, it means it isn't a text file, how come can I write something to it?

A text file can have any name. Even under Windows, a .txt extension is not mandatory, although Windows does use the extension to classify files into what type it thinks they are, so it won't show up as a "Text Document" (I think that's what Microsoft currently calls them...) in the filesystem browser if the extension isn't there.

And you can read from and write to binary (non-text) files, too. There is no "text files only" restriction. Just don't expect any particular internal structure from binary files unless you know them to be in a specific format.

[cupidvogel]

Thanks.