-- Randal L. Schwartz, Perl hacker

turnstep's reply made me realize that the second half of the above proposal isn't portable. Recording the file size doesn't do you that much good except on Unix. If you start a script a while later and you want to read what lines were added since the last time that the script ran, then you need to know the seek offset to the previous end of the file; and this isn't the file size except on Unix (at least is isn't for DOS, Win32, OS/2, MacOS, nor VMS).

Another problem is to detect when the file has been replaced and you need to start from the beginning again. Checking for a changed i-node number (from stat) works pretty good, even on many non-Unix systems. But even under Unix, it misses some cases (and gives a false positive on other rare cases). Just noticing that the file got smaller is often an acceptable method. You can also cache the first few and/or last few lines and compare those quite quickly (or just remember the seek offset right before the last newline and check that the character at that offset is still a newline). Or combine all of these and reread the whole file if any of them fail, for example.

This type of approach can be quite nice if you don't need the lines processed immediately. It doesn't require one more process always hanging around. It is easy to "catch up" if something goes wrong.

        - tye (but my friends call me "Tye")

You could also use some combination of seek and tell to emulate a tail -f (although you are probably better off using File::Tail) Basically, you open the file for reading, process all the lines, sleep a little, run seek to clear the EOF flag (without moving the cursor, such as seek(MYFILE,0,1)) and then trying to read in a line again (e.g. with <>) You could also use tell to save where you are in the file, and seek to that spot upon reopening it. Or use -s $filename to keep re-checking the size of the file. Definitely MTOWTDI!

The downside of this is that your code is probably less modular. I suspect that the other processes that you would be inclined to run have little to do with logging someone on and off. Therefore, those processes don't belong in a long script. Perhaps have that script run another Perl program every time someone logs on and off? If you have a high traffic system, this could also be a Bad Thing as it would likely slow everything down. I mention these alternatives to help you consider the possibilities, not that I think they are necessarily appropriate for your situation.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

I'll have to think of something to fill this with...

It ain't Perl, but rather than make you deal with a double post (and in lieu of submitting an editor request), I'll torture you with one of my favorite poets -- Ovid.

Elegy 9B

I'll spare you the rest...

Cheers,
Ovid

Update: Hoist on my own petard! d4vis needs a good spanking :)

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

(Sorry, it's just too ironic to pass up)
Please see this node on how to avoid double posting. :}

~acolyte d4vis
#!/usr/bin/fnord

You've got something personal against HP/UX?

--Chris

e-mail jcwren