Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Line Numbers

by Sprad (Hermit)
on Oct 17, 2003 at 21:04 UTC ( #300165=perlquestion: print w/replies, xml ) Need Help??

Sprad has asked for the wisdom of the Perl Monks concerning the following question:

Is it possible to get the line number of the currently running program? I'm doing some logging and it would be useful to include line numbers (and filenames too, if possible) within the log. warn gives both, but I need to fit that info into my own log lines.

---
A fair fight is a sign of poor planning.

Replies are listed 'Best First'.
Re: Line Numbers
by BazB (Priest) on Oct 17, 2003 at 21:15 UTC

    Use __LINE__


    If the information in this post is inaccurate, or just plain wrong, don't just downvote - please post explaining what's wrong.
    That way everyone learns.

Re: Line Numbers
by hey_david (Sexton) on Oct 17, 2003 at 21:26 UTC
    Alternatively, if you're logging within a separate function (or even module), you can get both the filename and the line number of the caller, with:

    my ($package, $filename, $line_number) = caller();
Re: Line Numbers
by sweetblood (Prior) on Oct 17, 2003 at 21:20 UTC
    The line number is __LINE__ and the script name is $0.
      Note that __LINE__ is usually relative to the top of the script's file:

      print __LINE__, "\n"; print __LINE__, "\n"; eval {print __LINE__, "\n";}; __OUTPUT__ 6 7 8

      The preceeding code prints three sequential numbers. I bring this up because it could be guessed (or hoped) that __LINE__ might be relative to the top of the code being processed in the eval block. In fact, it is not, if it uses eval's {block} syntax.

      However, __LINE__ will return a different result if you wrap the eval'ed code in quotes. See the following code:

      print __LINE__, "\n"; print __LINE__, "\n"; eval "print __LINE__,qq/\n/; print __LINE__,qq/\n/; die()"; print $@, "\n"; print __LINE__, "\n"; __OUTPUT__ 6 7 1 3 Died at (eval 1) line 5. 12

      As you can see, that code prints the 6 and 7 as absolute file linenumbers. But the 1 and 3 are loosely relative to the quoted eval material. The "line 5" generated by trapping the die shows the odd behavior that in the case of lines of code eval'ed within quotes line numbers seem to skip a number for each line. Finally, the printing of '12' indicates that once back outside the eval function, the original numbering scheme resumes, unaffected by eval's apparent reset of __LINE__. So line must be localized within quoted eval strings.

      I'd be interested in seeing any documentation for this behavior.


      Dave


      "If I had my life to do over again, I'd be a plumber." -- Albert Einstein

        The problem here is that your "\n" line ending within your eval string are being interpolated before the string is eval'd. Effectively, you are double spacing your lines of code. escaping the "\n"s, make the problem go away.

        P:\test>perl print __LINE__, "\n"; print __LINE__, "\n"; eval "print __LINE__,qq/\\n/; print __LINE__,qq/\\n/; die()"; print $@, "\n"; print __LINE__, "\n"; ^Z 1 2 1 2 Died at (eval 1) line 3. 7

        I've fairly recently started coding my (rare) uses of eval like this.

        #! perl -slw use strict; print __LINE__; print __LINE__; eval <<"EOS"; # line 1 "@{[__PACKAGE__]} eval @ line @{[__LINE__]}" warn; warn; die(); EOS print $@; print __LINE__; __END__ P:\test>junk 4 5 Warning: something's wrong at main eval @ line 6 line 1. Warning: something's wrong at main eval @ line 6 line 2. Died at main eval @ line 6 line 3. 14

        This allows you to get very useful error messages from within the evals, telling you not only which line number within the eval failed and why, but also the package name and line number at which the eval is located. Not so important when the eval is in main as here, though knowing which line number is useful if there are more than one in the file, but it really comes into it's own when the eval is located in a module.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        Hooray!

      please use __FILE__

      Actually $0 is the currently executing program, which varies system to system. See perlvar for more detail.

      On Solaris 8, it's likely to be something like /usr/bin/perl /path/to/perl/script, not at all like the filename given by warn or die.
      On Linux (or at least this Linux box) it is the script name.

      Update: Correction; after re-reading perlvar myself, it states "$0...Contains the name of the file containing the Perl script being executed".
      However, my comment about it varying OS to OS stands.

      Update 2: I am an idiot. I've double checked, following vek's post (++); he's quite right. $0 does exactly as advertised.
      All I need to do now is remember where I saw a script reported as I originally and incorrectly reported - ps probably. *Sigh*


      If the information in this post is inaccurate, or just plain wrong, don't just downvote - please post explaining what's wrong.
      That way everyone learns.

        Actually on Solaris 8 it's just /path/to/perl/script.

        #!/usr/bin/perl print $0, "\n";

        Prints /path/to/perl/script on Solaris 6, 7, 8, 9 - I just ssh'd into work to test it out :-)

        -- vek --

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://300165]
Approved by davido
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (9)
As of 2019-06-26 16:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Is there a future for codeless software?



    Results (110 votes). Check out past polls.

    Notices?