open (MYFILE, '+<pathname')

Second, the system implicilty remembers the position within the file,
so if you want to do things at different positions, you'll have to use
tell() to read the position and seek() to set it.

If you want to freely intermix reading an appending, you'll want
to do something like this:

        open (MYFILE, '+<pathname') or die;

        $append_position = tell MYFILE;         # it should start at the end
        $read_position = 0;
        $mode = 'append';

        # switch to mode where you can read
        if ($mode eq 'append')
        {
            $append_position = tell MYFILE;
            seek (MYFILE, $read_position, 0) or die;
        }

        # read some stuff

        # switch back to mode where you append
        if ($mode eq 'read')
        {
            $read_position = tell MYFILE;
            seek (MYFILE, $append_position, 0) or die;
        }

        # now you can append some stuff

If you don't want to intermix reading and appending, then you don't
need to save your place, so it's a little easier.  You just do

        seek (MYFILE, 0, 0);

before you start reading, and you do

        seek (MYFILE, 0, 2);

before you start appending.

  - Logan
--
"In order to be prepared to hope in what does not deceive,
 we must first lose hope in everything that deceives."

        open (MYFILE, '+>>pathname')

works too, IIRC. You'll need to seek back to 0 if you want to read the
file, first.

Oh, and note that some OSes demand that you do a seek before switching
from read to write, even if you're absolutely sure that the file
position pointer is positioned correctly. I have had this bad experience
with ActivePerl (Win32; but I'm not sure it was 5.005_x or 5.6.x).

close(MYFILE);

This opens the file on read-only mode, puts each line of MYFILE into an


append anything, you could reopen the file in append mode like this;

open(MYFILE, ">>filename");
print MYFILE "some stuff i want to append";
close(MYFILE);

Or you could open the file in read/append mode, and keep it open the entire
time, so;

[many read operations on the filedata array]
print MYFILE "some stuff i want to append";
close(MYFILE);

But since you're only using the file for appending once at the end, it seems
silly to me to keep it open for the duration of your program!

Regards,

Well, not unless the file is on the far end of some sort of network file
system which needs to have a tcp connection maintained as long as the
file is open.  How often is this the case?

Hmm, or unless the number of open file descriptors you're allowed is
very very small, and there're a number of files opened and closed
between the reading and appending stages of MYFILE.  I think some
versions of DOS may only allow 255 or 65535 open files at one time.

If you ever might want to do file locking, it's *definitely* not silly.

Another consideration is that open,read,close,open,write,close takes two
more operations than does open,read,write,close, and thus is likely to
slow you down.

Actually, if it does, that might be a good thing, because keeping open
a TCP connection requires basicaly no processing.  It just requires
state to be stored somewhere (i.e. memory is used).  And if you close
the TCP connection and re-open it later, then you have to wait for the
TCP connection to gradually grow its window size again to adjust to the
available bandwidth.

  - Logan
--
"In order to be prepared to hope in what does not deceive,
 we must first lose hope in everything that deceives."

About that 'requires state to be stored somewhere' ... if the file
server has very limited memory, and very high load, and if your script
takes a long time between reading and writing, and if the overhead of
closing/opening the file is less than the cost of keeping the file open,
then you might, in that one case, gain an advantage from closing after
reading and reopening for writing.