+Use of uninitialized value $. in range (or flip) at - line 12.
+Use of uninitialized value $. in range (or flip) at - line 14.
Its certainly an improvement, insofar as it leaves a specific clue,
but the average joe wont know that:
$. is line-number on an input filehandle,
so it must be magically going to stdin in scalar context ?????
$ perl -wpe 'my $x = (1 .. 2);' /dev/null
did giving perl empty input fix the uninit-var connected to your $.
fwiw splain doesnt help (clarify the underlying $.) either:
perl -we 'my $x = (1 .. 2)' 2> junk ; splain junk
Use of uninitialized value in range (or flip) at -e line 1 (#1)
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.
To help you figure out what was undefined, perl will try to tell you the
name of the variable (if any) that was undefined. In some cases it cannot
do this, so it also tells you what operation you used the undefined value
in. Note, however, that perl optimizes your program and the operation
displayed in the warning may not necessarily appear literally in your
program. For example, "that $foo" is usually optimized into "that "
. $foo, and the warning will refer to the concatenation (.) operator,
even though there is no . in your program.
Actually, that explanation is distracting, and hilights the fact that
your patch gives the only mention of $.
Any chance that other file-handle special vars are affected ?
does your patch magically report them too ?
(Im not thinking of any example, sane or otherwize, just conjecture)