in reply to Re: Why Does the Hash Seem Empty?
in thread Why Does the Hash Seem Empty?

Thank you.

A much better way of identifying that a hash is not empty.

Why would the perl interpret a separate while loop TO CONTINUE from a previous one?

That doesn't make sense to me at all.

I just did your change and it worked. Thanks again as the files it produces are needed on Saturday at 3AM! :-)

Tony

Replies are listed 'Best First'.
Re^3: Why Does the Hash Seem Empty?
by imp (Priest) on Jul 20, 2007 at 19:54 UTC
    From each:
    There is a single iterator for each hash, shared by all each, keys, and values function calls in the program; it can be reset by reading all the elements from the hash, or by evaluating keys HASH or values HASH .
    Perl isn't continuing a while loop, it is starting a new while loop, but your loop condition is the hash iterator, which was not reset.
Re^3: Why Does the Hash Seem Empty?
by yaneurabeya (Novice) on Jul 20, 2007 at 19:56 UTC

    From perldoc -f each:

    ========================

    When the hash is entirely read, a null array is returned in list context (which when assigned pro­duces a false (0) value), and "undef" in scalar context. The next call to "each" after that will start iterating again. There is a single iterator for each hash, shared by all "each", "keys", and "values" function calls in the program; it can be reset by reading all the elements from the hash, or by evaluating "keys HASH" or "values HASH". If you add or delete elements of a hash while you're iterating over it, you may get entries skipped or duplicated, so don't.

    ========================

    So, it's a function of the way that each is designed at a lower level -- to preserve iterator locations unless keys or values is re-run, most likely a similar methodology to the way C's strtok(2) works by first specifying the target string, then being able to specify NULL for the first arg and picking up where you last left off.