Pseudocode looks currently like this:
open logfile
open other file
grab line if it matches
now look in other file for same pattern match
if that line matches, we have our two values
otherwise keep looking
compare two values
do things
close logfile
close other file
I know this is inefficient, and I know that the usual way to do things
is to comb through the logfile first, grab every line you need to
match, and then match THOSE against the second file. I'm just worried
that I'm going to eat TONS of memory if I adopt this solution.
What I try to do above is to open both files first, and then as I scan
through the second file, to leave the file pointer "where it is" when
I find what I need, and hopefully resume scanning from where I left
off (so I don't have to read the second file in its entirety again).
I can do this because of the chronological ordering.
The simple question, therefore, is: Is there a way to do something like this:
while ($thing = <FILEHANDLE>) {
last if $thing =~ /information/i;
}
# do some stuff; suppose we left off at line 3000 above
while ($thing = <FILEHANDLE>) {
# continue from line 3001
}
If there ISN'T a way to do something like this, does anyone have any
suggestions? :) My guess is that the "last" operator up there--what,
resets the file pointer? Not sure, but with code like the stuff
above, I keep getting the first match from the second file.
Cheers,
Laird
--
laird j. nelson (617) 252-5147
at&t new media services You Will. 25 first street
http://www.amherst.edu/~ljnelson/ cambridge, ma 02141
I do not speak for my employer, and my employer does not speak for me.
That code does exactly what its comments describe.
> My guess is that the "last" operator up there--what, resets the file
> pointer?
Nope.
> Not sure, but with code like the stuff above, I keep getting the first
> match from the second file.
I'm afraid that snippet wasn't enough to point out the problem. Try to
whittle the code down to the smallest amount with which you can
reproduce the problem. If this doesn't lead you to what's going wrong
post what you end up with and somebody else might be able to spot it.
--
Roderick Schertler
rode...@gate.net