This is perl 5, version 12, subversion 2 (v5.12.2) built for x86_64-li
+nux

This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-li
+nux-thread-multi
[download]

Check for unexpected line endings? cat -A

Any chance some of your lines end with CRLF and some just with LF? Check the file with a hexaeditor.

I tried that, it was actually lines that ended only with a carriage return that didn't increment the value of __LINE__.

It's probably what causes phramus's problem I guess. If not, I only know of two other ways to have __LINE__ (which is replaced at compile time, so should not be affected by runtime operations) corresponding to something else than what seems obvious: source filtering and the #line directive:

package Third;
use Filter::Util::Call;
$\ = $/; $, = ":";
print 4, __LINE__;
## Hello
BEGIN { filter_add ( sub { $status = filter_read(); $_ = "" if /^##/; 
+return $status; } ); }
print 7, __LINE__;
## World;
print 9, __LINE__;
#line 42
print 11, __LINE__;
[download]

4:4
7:7
9:8
11:42

There the source filtering removes all lines starting with two #, but it has no effect on lines before the filter function is added, even though it's in a BEGIN block. So if the problem is source filtering, it has to be from a module included earlier (in the command used to run the script for example). And well, if phramus used #line 42 like comments in his script to keep track of the line number, that's tough luck.

Lines ending with either CRLF (\x0d\x0a) or LF (\x0a) are usually fine, even when mixed in the same source file. Lines ending with CR (most commonly Mac OS 9 and earlier, or just plain broken source code) will be seen as one line.

The following produces the same output for me on both Linux (5.18) and Windows (Strawberry 5.16):

use 5.010;
use warnings;
use autodie;

for (qw<CRLF LF CR>) {
    say "Testing with $_ line endings:";
    
    open my $perl, '|-', 'perl';
    select $perl;
    local $\ = $_ eq 'CRLF' ? "\x0d\x0a" : $_  eq 'CR' ? "\x0d" : "\x0
+a";
    
    print 'use strict;'; 
    print 'use warnings;'; 
    print 'print "This is line ", __LINE__, "\n\n";';
    
    close $perl;
    
    select STDOUT;
}
[download]

To see the line endings in a file, use a hex editor, or this:

use File::Slurp;
 
$_ = read_file($ARGV[0] // $0);
s/<(CR|LF)>/\\<$1\\>/g; # "Escape" existing
s/\x0d/<CR>/g, s/\x0a/<LF>/g;
s/((?:<CR>)?<LF>)/$1\n/g; # Add real line breaks
say;
[download]

The only other thing I can think of is possibly a source filter, but if you are getting those results on a 5-line test with no source filter, scratch that.

OK. Progress has been made. It wasn't the line endings, per se, but rather some garbage apparently being added to some lines. I had been using Padre since taking up Perl a couple of weeks ago. After your comments, I loaded the offending file into Textpad, only to observe that the problem persisted and that the line endings looked OK (with "view whitespace", anyway). In a rare moment of lucidity, I saved the file and reloaded it; and the problem was gone! My Textpad is configured to "strip trailing spaces" when saving. So some extraneous content, invisible, apparently existed on random lines. Perl is off the hook.

This probably also explains some strange error messages that I've had, which were only resolved by deleting and retyping the indicated content with what was visually identical content. So Perl is off the hook for that, too.

Thanks guys. I probably should have thought of cleaning up the line endings earlier, but I didn't until prompted. Now I'll be looking for a different editor (Win 7 64-bit).

... I'll be looking for a different editor ...

The search for a comfortable editor is so tedious that when we find one, it usually has to be pried from our cold, dead hands. But be aware that the authors of most modern programmer's editors know that we live in a very diverse world, and they have made great efforts to accommodate every possible text file format variation and make them all 'look' right. You may encounter an editor with a default configuration that matches your assumptions about text files, but never assume these are the only configurations (or assumptions) possible.

My Textpad is configured to "strip trailing spaces" when saving. So some extraneous content, invisible, apparently existed on random lines.