# always test for failure

open (FILEHANDLE, "+< $filename") || die "Can't open $filename in upda
+te mode: $!\n"; 

# read entire file into array of lines

@array = <FILEHANDLE>; 

# do stuff to the file here

# go back to beginning of file handle

seek(FILEHANDLE, 0, 0) or die ("Seek failed on $filename: $!\n"); 
print FILEHANDLE @array or die ("Print failed on $filename: $!\n"); 

# truncate the file so we don't have excess garbage at the end

truncate(FILEHANDLE, tell(FILEHANDLE)) or die ("Truncate failed on $fi
+lename: $!\n"); 
close (FILEHANDLE) or die ("Close failed on $filename: $!\n");
[download]

Please note that flocking a file doesn't stop others from playing with it. They can still modify the file if they don't check to see if it's flocked.

Further resources:

• I don't know if you're aware of this, but perlmonks has a lot of useful information that can be read.
• Perl.com
• CPAN

Cheers!

PS: I took the above code straight from the Perl Cookbook. Beg your parents for a copy.

On a non-braindead operating system, many processes can simultaneously acquire a shared lock on a file, but an exclusive lock can only be held by one, and it usually blocks until all other locks (including shared locks) are released.

You have a couple of options. You could open the file for read/write access with an exclusive lock, at the beginning of your program. That's conceptually simple, but you'll have to "rewind" it after reading, if you want to overwrite it. (See seek.) It also has the drawback that if another process has any lock on the file, your program will block (unless you work around it). This is the technique I'd choose.

You could also continue with the code above. If you don't close the filehandle explicitly, Perl will do that for you implicitly. Closing a filehandle has the side effects of flushing buffers and unlocking any locks on it.

I doubt your code to open the filehandle to a different file and acquire an exclusive lock is an atomic operation. (It probably takes more than one processor cycle to accomplish, so there is a possibility another process could jump in there and grab a lock. Of course, any process that doesn't check for locks could do that anyway.)

The best advice I can think of is to make sure that any other process that might access the file also use the same flock technique you decide on.

Disclaimer: I'm not as smart as I seem, sometimes.

open FILE, "+>>file.txt" or
open FILE, "+<file.txt" or
open FILE, "+>file.txt"
[download]

opening for +> is generally rather silly, since you've just zeroed out the file on the second open. :)

-- Randal L. Schwartz, Perl hacker

flock blocks until the lock is acquired. That is, LOCK_EX doesn't return until all current shared locks are released, and LOCK_SH doesn't return until any exclusive lock is released. Normally, you don't check to see if a file has been locked, you simply ask for the lock and go about your business.

This is all in the perlfunc manpage, though the 5.6 docs are clearer...

Two potentially non-obvious but traditional flock
semantics are that it waits indefinitely until the
lock is granted, and that its locks merely
advisory.  Such discretionary locks are more
flexible, but offer fewer guarantees.  This means
that files locked with flock may be modified by
programs that do not also use flock.