in reply to Playing with non-localized $_ in nested loops.

The extra info is included whenever perl's last input filehandle is set (by readline, eof, tell, or sysseek) and $. is true. close resets $., and so will supress the info. I'm trying to come up with an harmless way of suppressing it in general; the best I can do is: 
{
   local $.; scalar tell STDOUT;
   warn "whatever";
}

[download]
Localizing $. doesn't do what you might expect; instead of doing anything to the actual value of the line number of the current input file, it only sets up the local input filehandle itself to be restored at the end of the block.

Replies are listed 'Best First'.
Re^2: Playing with non-localized $_ in nested loops.
by davido (Cardinal) on Aug 23, 2004 at 02:41 UTC

    I've often wished that $. could be %. instead. That way, $.{FH} could refer to <FH>, and $.{DATA} could refer to <DATA>. But this all breaks down when you start talking about lexical scalar filehandles ( <$fh> ), because how would you write that? $.{\$fh}? ...it starts looking a little ackward.

    I've also often wished that it would actually "do" something when you assign a number to $. But of course this is asking way too much of the buffered IO subsystem, and when that sort of behavior is desired, it's almost always easier to just use Tie::File.


    Dave

[reply]
[d/l]
[select]
      I've also often wished that it would actually "do" something when you assign a number to $.
      Just think what this would mean: 
      $. = 10.7;

      [download]
      Does that mean we can now start reading from the character at position 70% on line 10? Or is that the 8th character? [And how do I get rid of the headache that just gave me?]

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

[reply]
[d/l]

        Perl dwims nicely when you use a float in other situations where an int is expected. 

        my @a = 0 .. 9;
print $a[3.5];
3

        [download]

        It could do the same here. If the number involved required advancing from the current position, it just reads and discards enough lines to get to where you want to be.

        The problem arises if you want to backup. That would require keeping the file positions of every line seen so far. On large files, that's a lot of storage. If you store integers in a perl array, they take as much space as storing the lines themselves until the lines get greater than 20 chars or so.

        You can save some space by storing the offsets in a C-style array (eg. pack them into a string) but with if your going to handle files greater than 2/4GB, then you need to store 8 bytes/line, and that still chews a substantial amount of memory to provide a rarely used facility.

        Though, I guess if it rewound to the beginning and discarded until it reached the position required it wouldn't require extra storage. It would simply be doing what you have to do yourself to achive the same results, but hiding it behind a simple assignment... which might be nice.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]

In Section Seekers of Perl Wisdom