At 06:16 PM 1/7/03 -0600, Christopher D. Lewis wrote:
>On Tuesday, January 7, 2003, at 11:19 AM, Peter Scott wrote:
>
>>[responding to replacement of sub displayResults with {print __LINE__
>>. " sub displayResults";}]
>>That needs to be __LINE__, not __line__. The above is an error.
>>You do have -w and use strict in this program, right?
>
>When I use "__LINE__, "... in a test script[1] I get:
>No comma allowed after filehandle at print_line.pl line 5.
>
>When I use "__LINE__ . "... in a test script[2] I get:
>__line__ sub displayResults
Well, you've got something weird going on in any case. I'll get to it.
>(I had imagined __LINE__ might have been intended to print the line
>number in which Perl thought the line occurred,
Correct, it does.
>but then, I am not familiar with "__" in Perl ...)
There are three special tokens, the __ is part of them. They are
__LINE__, __FILE__, and __PACKAGE__. See perldata. But I digress.
>I had "-w" in use in my original scrips, but not "use strict"; adding
>"use strict" to the script with sub displayResults disemboweled reveals:
> chris% dice/nudice-01c
>Global symbol "$request" requires explicit package name at
>dice/nudice-01c line 32.
>Global symbol "@input" requires explicit package name at
>dice/nudice-01c line 41.
[snip many errors]
You made a false economy by not using strict. Yes, you would have to
fix those errors - mostly due to not declaring *everything* with
'my'. But to leave it out is to shoot yourself in the foot.
You have managed to blow your whole leg off with a .22.
>... and I have no idea what an explicit package name is :-) At your
>request, I have placed the whole, ugly thing at
>www.PuckU.org/misc/nudice-01c for inspection of why Perl thinks the
>line numbers are as it reports ...
And here's where. At the end of the definition of processArgs you have
an extra character after the block end:
}s
That one character causes Perl to think that you are introducing a
substitution operator, which happens to find in your next non-blank line:
sub parseArg { # Parses request ...
text to allow it to close the substitution and think that the modifiers
for it are 'e' and 's'. Thereby creating an evaluating substitution
whose evaluation code contains unbalanced braces and a comment... I do
not know how this results in the line numbers getting screwed up, but
the fact is that after that statement, Perl starts counting TWO lines
for every one in your source. It is possible to see the effect with a
'program' as small as this:
#!/usr/bin/perl -w
s
sas{#se
BEGIN{print STDERR __LINE__,"\n" }
BEGIN{print STDERR __LINE__,"\n" }
BEGIN{print STDERR __LINE__,"\n" }
To call this bizarre would be an understatement. I will post this
snippet to perl5-porters to see if anyone can tell me why the line
numbers get screwed, although since this is a syntactically invalid
program anyway it may not get much attention.
Head swimming yet? Then consider this: if you had been using strict,
and ensuring that you had no errors, you would have found the problem a
lot faster. I wish I could say that it would have told you "additional
characters after subroutine definition", but it's not that
simple. However, you would have seen a lot of error messages for
things happening after that line that on closer inspection would have
appeared impossible, thereby prompting you to start searching backwards
from that point. Fortunately, you indented well, so it wasn't hard to find.
But you did get quite unlucky, nonetheless. But use strict - it is your
friend!
--
Peter Scott
http://www.perldebugged.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
