Line Numbering?

[audiopro]

When Perl reports an error it gives an approx line number where the error occurred.
How do I find the line in question without counting through the script.


Keith

http://www.studiosoft.co.uk

 

[TrojanWarBlade]

Use an editor that has a "goto line" feature and/or can show line numbering.



(slowly healing) Trojan.

 

[PaulTEG]

#!/usr/bin/perl
$file=$ARGV[0];
$line=$ARGV[1];
open FH, "<$file";
while (<FH>) {
  if ($loop == $line) {
     print $_;
  }
  last;
}
close FH;

perl script.pl filename.cgi 23

NOT TESTED

Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[duncdude]

What editor do you use? BBEdit for OSX has line numbers...


Kind Regards
Duncan

 

[TrojanWarBlade]

You could use perl to do it:

perl -lne '$. == 9 and print ">>> $_" or print "    $_";' broken_script.pl

Change the 9 for any line number you like.




(slowly healing) Trojan.

 

[audiopro]

I use various editors depending on which machine I am using.
I wrote a simple routine which displays a selected line but wondered if there was something within PERL itself.
Thanks for the replies.


Keith

http://www.studiosoft.co.uk

 

[TrojanWarBlade]

Perl is a language, not an editor.
I did show you an example above though of how you could use perl to show you where the problem is.


Trojan.

 

[audiopro]

Thanks TrojanWarBlade, your example does the same as the routine I am using. I was checking this out as I have recently discovered numerous flaws in the way I was taught PERL.

Keith

http://www.studiosoft.co.uk

 

[TrojanWarBlade]

Let us know what you're not happy with in your understanding of perl and we'll try to make things clearer for you.
I have taught numerous people in my time and there are many others here that have excellent perl skills. You have an audience of teachers at your disposal!



Trojan.

 

[audiopro]

I learnt PERL from a book which makes no mention of STRICT, WARNINGS and the $query syntax, which means that the scripts I have written fail miserably when run under these conditions. I have written quite a number of scripts using global vars and they all run with no errors. They errored while being written of course but once tested were OK.
I see no reason to re-write the scripts which have been written and have worked without fault ever since but I am using my new found knowledge on my latest work. I asked the question about line numbers purely out of interest in all things PERL. Locating the line on which an error occured isn't usually a problem as it will almost certainly be the last bit I edited.
I found STRICT and WARNINGS very annoying at first but have since learnt to live with them and find they are extremely useful. I am learning MySQL and my only regret is that I didn't learn it years ago as it is simplifying many of the file manipulation tasks which I need to perform. I have some questions about form handling with MySQL but I will start a new thread in order to keep things tidy. I find this forum both helpful and informative and I am grateful for the advice offered willingly by the many participants.

Keith

http://www.studiosoft.co.uk

 

[TrojanWarBlade]

If you had not heard of strict and warnings then you probably also have not heard of "use diagnostics". You might like to try that on occasion to see what it does (more verbose error messages and advice).
With respect to re-writing your old scripts, I'm in two minds.
I understand that you don't want to repeat work and/or risk upsetting working code but you could easily have dormant bugs that are waiting to bite.
I might be tempted to modify copies of them to run with strict and warnings, just to see if there are any obvious nasties, even if you have no intention of replacing the working copies.
If you are concened about global vars and "use strict" you needn't worry. You can run code with globals and use strict with no probs and very minor mods. All you need do is declare all your globals at the top of your code with "our" declarations:

use strict;
our $var1;
our $var2;
...
$var1 = 27;  # Will work fine
$bad  = 31;  # Will fail as not declared

This is great for picking up variables that you didn't know you were creating/accessing on the fly because of spelling errors. I recommend you give it a try.



Trojan.

 

[jonadab]

> I found STRICT and WARNINGS very annoying at first but
> have since learnt to live with them and find they are
> extremely useful.

Yeah, I don't always use strict for short scripts, but it is definitely handy for longer ones, *especially* anything long enough that you start thinking about splitting it into multiple files or breaking out some of the code into a module. You *definitely* want to use strict in situations where other people's code is going to be calling your code. And yes, it's easiest to make the code strict from the beginning, by design; converting an already-written non-strict script to run under strict can be a pain and is not always worth it. (Although, if it's so bad that the error is hard to find using Data:umper, it usually needs to be completely refactored anyway.)

 

[audiopro]

All my previously written scripts have been extensively tested in live situations and I think any problems would have shown themselves by now. I have always worked that way so I am used to checking if whether new vars already exist.
I am just having to get used to a new way of working.
Words such as 'tricks', 'dogs' and 'old' spring to mind.


Keith

http://www.studiosoft.co.uk

 

[TrojanWarBlade]

When I first learnt perl (many moons ago) I didn't use either warnings or strict and I had a bit of a shock when I checked some of my old code when I found out about them.
Ever since I use them both on all scripts.
And I re-engineered my old stuff to use them (which was much harder in those days before "our").
If you wish to leave your scripts as they are then that's your choice but I can't agree with you that you'd have found all the bugs by now. I have seen so many examples of code in my time that has run for years with bugs that people were not even aware of that I'd personally much rather be sure if I could.


Trojan.