I think you're right about that. It seems a risky way to accomplish what can easily be done with a temp file. I feel that unless there is some compelling reason to take such a risk, you're far better off just creating a temporary file and renaming it when you're done. I'm not even sure what the advantage might be to using the same filename for input and output. Just seems like you're asking for trouble. In my experience, trouble always manages to find me without my having to go looking for it.

Comment on Re: Perl Best Practices book: is this one a best practice or a dodgy practice?

I'm not even sure what the advantage might be to using the same filename for input and output.

I certainly don't suggest (either here or in the book) that you should use the same file for input and output. I merely observe that, if you allow people to independently specify input and output filenames on the command-line, some of them inevitably will use the same name for both files (either intentionally or accidentally). So you have to be aware of the possibility and cope with it somehow.

In the book, I suggest two solutions, one of which is more efficient but apparently fails on certain obscure operating systems (and, yes, I will definitely update the book to reflect that limitation, as soon as I can).

In that case, might it not be better to make the "best practice" exposition something like this?

When accepting command-line arguments that specify both an input file and an output file, be aware that eventually someone using your program will specify the same filename for both input and output. If your code looks like this:

then the result is going to be a blank output file! (or whatever it is your program produces given a blank input file). This isn't very friendly to the user. Slightly more userfriendly is to check for this condition in your code:

if ($infile eq $outfile)
{
die "Same filename given for both input and output!";
}

This protects against a user who accidentally uses the same filename for input and output, but doesn't protect against filenames which are different strings but name the same file (for example, "foo" and "./foo", or "foo" and "bar", if "bar" is a symbolic link to "foo")

However, it may be the case that the occasional user actually does want the output file to replace the input file, much as perl's own -i option does. Certainly, if possible, we should allow this since we want our programs to be useful to the user. In this case: (... and here continue on with the unlink trick, etc.)