Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!jarthur!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: a Perl bug??
Message-ID: <6983@jpl-devvax.JPL.NASA.GOV>
Date: 5 Feb 90 05:07:02 GMT
References: <2236@uvaarpa.virginia.edu>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 28

In article <2236@uvaarpa.virginia.edu> microcase!elvis!ling@nosun.west.sun.com writes:
: Is this a bug? I have seen it since perl 2.0. I beg your pardon if I
: misunderstand the use of $. and local.

: # local($_) works but not local($.).

[Script deleted.]

The $. variable antedated local() by quite some time.  And it was defined
as a read-only variable that gave the line count from the last read filehandle,
so that even if you assign it a value, when you read it, it retrieves the
value from the filehandle again.  For efficiency reasons I didn't want to
update the $. variable itself on each line read.

So when local() sets up for the value to be restored to $., it does it, but
you'll never see the value because you've changed the last read filehandle.
I don't want to change the line number in that filehandle, because the
reason we're presumably saving the value is that it belongs to another
filehandle somewhere.

So the current solution is to save the last read filehandle rather than
value of $., and restore that when the local block exits.  This has the
expected effect, and also lets you localize the last read filehandle, which
also can influence eof and tell.

Expect the fix in patch 9.  I'm not saying when to expect patch 9...  :-)

Larry