Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Bad line numbers .. bad!

by phramus (Novice)
on Jul 25, 2013 at 19:59 UTC ( #1046413=perlquestion: print w/replies, xml ) Need Help??
phramus has asked for the wisdom of the Perl Monks concerning the following question:


I have noticed errors in what perl reports for line numbers, and I'm wondering if some light can be shed here. In one script I'm working with:

package Args; use v5.10; use strict; use warnings; print __LINE__, "\n";
prints 4 for the line number when even I can see that it should print 5. This same script reports 162 for the final line number, when it is actually 181. That's a pretty big error! Moreover, if I add a line to the top of the file:
print __LINE__, "\n"; package Args; use v5.10; use strict; use warnings; print __LINE__, "\n";
it prints 1 and 4 .. the original 4 hasn't changed, and the original 162 at the bottom is still 162. If I add a blank line at the top, though, the subsequent line numbers increment properly (though they're still wrong).

To compound the weirdness, I can copy the lines above and paste them into a new file, which is otherwise empty, and the line numbers are correctly reported, though I suspect errors will creep in if I continue working in that new file. I have noticed similar shenanigans in other scripts I'm working with: The line numbering just gets worse as I go along.

Curiously, a web search doesn't find anyone complaining about this, so I thought I'd come here and ask. I'm using v5.14, the dwimperl release, by the way. Maybe I should update to a later release. Anyway, any wisdom you can offer will be greatly appreciated. Thanks.

Replies are listed 'Best First'.
Re: Bad line numbers .. bad! (__LINE__)
by toolic (Bishop) on Jul 25, 2013 at 20:09 UTC
    Your 1st code snippet prints 5 for me, as expected. I tried it on 2 versions of perl:
    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

    Check for unexpected line endings? cat -A

Re: Bad line numbers .. bad!
by Jenda (Abbot) on Jul 25, 2013 at 20:36 UTC

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

    Enoch was right!
    Enjoy the last years of Rome.

      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__;

      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.

Re: Bad line numbers .. bad!
by rjt (Deacon) on Jul 25, 2013 at 21:08 UTC

    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; }

    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;

    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.

Re: Bad line numbers .. bad!
by mtmcc (Hermit) on Jul 25, 2013 at 20:31 UTC
    It works fine for me too (v5.12.4). Do you definitely have new lines at the end of each line in your text editor?
Re: Bad line numbers .. bad!
by zork42 (Monk) on Jul 26, 2013 at 01:43 UTC
    My Textpad is configured to "strip trailing spaces" when saving. So some extraneous content, invisible, apparently existed on random lines.
    Trailing spaces should not make any difference to line numbers.

    I suspect that Textpad actually fixed some end-of-line problems as everyone else has suggested might be the cause.

    FYI I use Activestate's Komodo Edit for my editor (it's free), but it's not a proper IDE like Padre.
    Activestate's Komodo IDE is a proper IDE, but it costs $295 :(

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1046413]
Front-paged by BrowserUk
Discipulus definitevely shutted down a 12yo server

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2017-07-25 11:17 GMT
Find Nodes?
    Voting Booth?
    I came, I saw, I ...

    Results (370 votes). Check out past polls.