perl syntax check

[Helmut Richter]

I'd like to do a perl syntax check as distinct from an execution. I am
well aware that there are many errors that cannot be found without
execution but I'd like to first remove the errors that can be found
without execution and *then* execute the script. My attempt was using the
-wc flag, but this has no effect whatsoever.

> perl -wc ali.pl
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 362.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 363.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 365.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 419.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
[Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
ali.pl line 432.
[Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)
Status: 500
Content-type: text/html

<h1>Software error:</h1>
. . .


The script is intended as CGI Script. The format of the error messages, to
wit the same format as web server log entries and a status code 500, is
hardly conceivable as pure syntax error messages from perl. Rather, the
code must have been executed somehow. How could I prevent that?

--
Helmut Richter

[Ben Morrow]

Quoth Helmut Richter <hh...@web.de>:

> I'd like to do a perl syntax check as distinct from an execution. I am
> well aware that there are many errors that cannot be found without
> execution but I'd like to first remove the errors that can be found
> without execution and *then* execute the script. My attempt was using the
> -wc flag, but this has no effect whatsoever.

It does. -c makes perl stop at the end of the main compile-time phase,
exactly at the point where it stops invoking CHECK blocks and starts
invoking INIT blocks.

> > perl -wc ali.pl
> [Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
> ali.pl line 362.
> [Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)

<snip>
> Status: 500
> Content-type: text/html
<snip>

>
> The script is intended as CGI Script. The format of the error messages, to
> wit the same format as web server log entries and a status code 500, is
> hardly conceivable as pure syntax error messages from perl. Rather, the
> code must have been executed somehow. How could I prevent that?

'use' statements happen at compile time. (That's the point.) This means
that any code executed as part of a module's ->import method will be run
even under -c. Presumably you are using some module (CGI::Carp?) that
hooks into $SIG{__WARN__} (or something similar) and changes the warning
format: the only way to stop that code from running is to comment out
the 'use' statement.

As a matter of good style, modules shouldn't do anything 'important'
(open files, connect to databases, print output...) during compile time,
but should wait to be asked. Since this *is* just a matter of style,
though, there is nothing preventing modules from ignoring it if they
choose to. CGI::Carp is slightly bending the rules in the interest of
making debugging possible for people with no shell access.

As for preventing it: you can't. For one thing, 'strict' and 'warnings'
are switched on by explicit code in their ->import methods; if you could
somehow prevent execution of any Perl at all you would find strictures
were never switched on. For another, your code probably wouldn't even
compile, since it probably needs subs imported at compile time: and an
->import method can do anything it likes, you can't restrict it to just
exporting symbols and nothing else.

That said, you may be interested in Perl::Critic, which performs static
linting of Perl code (without executing anything ever). Personally I
find it inflexible and irritating (I won't use a spell-checker, either),
but a lot of people seem to find it useful. It's based on Adam Kennedy's
PPI, which spends a long time explaining exactly why it's impossible to
parse Perl statically and then goes on to make a best-effort attempt
anyway.

Ben

[Tim McDaniel]

In article <j2jou8-...@anubis.morrow.me.uk>,

Ben Morrow <b...@morrow.me.uk> wrote:
>
>Quoth Helmut Richter <hh...@web.de>:
>> I'd like to do a perl syntax check as distinct from an execution. I
>> am well aware that there are many errors that cannot be found
>> without execution but I'd like to first remove the errors that can
>> be found without execution and *then* execute the script. My
>> attempt was using the -wc flag, but this has no effect whatsoever.
>
>It does. -c makes perl stop at the end of the main compile-time
>phase, exactly at the point where it stops invoking CHECK blocks and
>starts invoking INIT blocks.
>
>> > perl -wc ali.pl
>> [Fri Jan 20 16:51:56 2012] ali.pl: Variable "$body" is not imported at
>> ali.pl line 362.
>> [Fri Jan 20 16:51:56 2012] ali.pl: (Did you mean &body instead?)

>> Status: 500
>> Content-type: text/html
>>
>> <h1>Software error:</h1>
>> . . .
>>

>> The script is intended as CGI Script. The format of the error
>> messages, to wit the same format as web server log entries and a
>> status code 500, is hardly conceivable as pure syntax error
>> messages from perl. Rather, the code must have been executed
>> somehow. How could I prevent that?
>
>'use' statements happen at compile time. (That's the point.) This
>means that any code executed as part of a module's ->import method
>will be run even under -c. Presumably you are using some module
>(CGI::Carp?) that hooks into $SIG{__WARN__} (or something similar)
>and changes the warning format: the only way to stop that code from
>running is to comment out the 'use' statement.

I don't think the major problem is the log line format. His problem
statement is not so clear, but I think the problem is in the lines you
trimmed some of and that I restored above:

Status: 500
Content-type: text/html

<h1>Software error:</h1>
. . .

That appears to be running the actual code, despite (as your write)

>As a matter of good style, modules shouldn't do anything 'important'
>(open files, connect to databases, print output...) during compile
>time, but should wait to be asked. Since this *is* just a matter of
>style, though, there is nothing preventing modules from ignoring it
>if they choose to.

Just to be sure: Helmut, how is the CGI output being generated?
Surely it isn't
BEGIN {
print standard_HTTP_header();
print "<html>\n<head>\n"; ...
}
... or is it?

--
Tim McDaniel, tm...@panix.com

[Ben Morrow]

Quoth tm...@panix.com:

> In article <j2jou8-...@anubis.morrow.me.uk>,
> Ben Morrow <b...@morrow.me.uk> wrote:
> >
> >'use' statements happen at compile time. (That's the point.) This
> >means that any code executed as part of a module's ->import method
> >will be run even under -c. Presumably you are using some module
> >(CGI::Carp?) that hooks into $SIG{__WARN__} (or something similar)
> >and changes the warning format: the only way to stop that code from
> >running is to comment out the 'use' statement.
>
> I don't think the major problem is the log line format. His problem
> statement is not so clear, but I think the problem is in the lines you
> trimmed some of and that I restored above:
>
> Status: 500
> Content-type: text/html
>
> <h1>Software error:</h1>
> . . .
>
> That appears to be running the actual code, despite (as your write)

Assuming this is CGI::Carp, that output is almost certainly coming from
the __DIE__ handler. This is running because perl is dieing at compile
time, due to there being a fatal compile-time error (probably a syntax
error) somewhere in the code. If the code were correct it would stop
without producing any output.

Ben

[Helmut Richter]

On Fri, 20 Jan 2012, Ben Morrow wrote:

> Assuming this is CGI::Carp, that output is almost certainly coming from
> the __DIE__ handler. This is running because perl is dieing at compile
> time, due to there being a fatal compile-time error (probably a syntax
> error) somewhere in the code. If the code were correct it would stop
> without producing any output.

Yes, it is certainly from "use CGI::Carp qw(fatalsToBrowser);" which I use
while debugging -- later without the fatalsToBrowser. It works fine for
errors at run time but not at compile time. It would be nice it did, just
sending the syntax errors to the browser screen, but it doesn't: the
browser gets an error 500 and the syntax errors go to the Nirwana.

Commenting out this line when doing syntax checks only is an acceptable
option.

Thank you.

--
Helmut Richter

[Willem]

Helmut Richter wrote:
) On Fri, 20 Jan 2012, Ben Morrow wrote:
)
)> Assuming this is CGI::Carp, that output is almost certainly coming from
)> the __DIE__ handler. This is running because perl is dieing at compile
)> time, due to there being a fatal compile-time error (probably a syntax
)> error) somewhere in the code. If the code were correct it would stop
)> without producing any output.
)
) Yes, it is certainly from "use CGI::Carp qw(fatalsToBrowser);" which I use
) while debugging -- later without the fatalsToBrowser. It works fine for
) errors at run time but not at compile time. It would be nice it did, just
) sending the syntax errors to the browser screen, but it doesn't: the
) browser gets an error 500 and the syntax errors go to the Nirwana.

Odd, it's supposed to send the compile time errors as well.
Have you turned off 'pretty errors' in your browser?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[David Combs]

In article <slrnjhjiir...@toad.stack.nl>,

Willem <wil...@toad.stack.nl> wrote:
>
>Odd, it's supposed to send the compile time errors as well.
>Have you turned off 'pretty errors' in your browser?

What browsers have a "pretty errors" feature?

Would emacs be one of them?

Thanks,

David

[Tad McClellan]

emacs is a "browser"?


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.

[Ben Morrow]

Quoth Tad McClellan <ta...@seesig.invalid>:

> David Combs <dkc...@panix.com> wrote:
> > In article <slrnjhjiir...@toad.stack.nl>,
> > Willem <wil...@toad.stack.nl> wrote:
> >>
> >>Odd, it's supposed to send the compile time errors as well.
> >>Have you turned off 'pretty errors' in your browser?
> >
> > What browsers have a "pretty errors" feature?

IE, most notably. By default it has a 'feature' which causes it to
ignore the body of any HTTP response which isn't a 200 in favour of a
built-in 'friendly' error page, *unless* the body returned is larger than
(IIRC) 1024 bytes. I believe recent versions of FF have picked up the
same nasty trick.

> > Would emacs be one of them?

Almost certainly not, though I don't use it so I don't know for sure.

> emacs is a "browser"?

w3-mode?

Ben

[Shmuel Metz]

In <9thmv8-...@anubis.morrow.me.uk>, on 02/01/2012

at 01:42 AM, Ben Morrow <b...@morrow.me.uk> said:

>IE, most notably. By default it has a 'feature' which causes it to
>ignore the body of any HTTP response which isn't a 200 in favour of a
>built-in 'friendly' error page, *unless* the body returned is larger
>than (IIRC) 1024 bytes. I believe recent versions of FF have picked
>up the same nasty trick.

Ouch! Can it be disabled?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Ben Morrow]

Quoth Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid>:

> In <9thmv8-...@anubis.morrow.me.uk>, on 02/01/2012
> at 01:42 AM, Ben Morrow <b...@morrow.me.uk> said:
>
> >IE, most notably. By default it has a 'feature' which causes it to
> >ignore the body of any HTTP response which isn't a 200 in favour of a
> >built-in 'friendly' error page, *unless* the body returned is larger
> >than (IIRC) 1024 bytes. I believe recent versions of FF have picked
> >up the same nasty trick.
>
> Ouch! Can it be disabled?

Yes, I think the preference is called something like 'friendly HTTP
errors', but those writing websites can't assume their users have turned
it off. As a result, a lot of error pages now have something like

<!-- padding for IE
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<to 1024 bytes>
-->

somewhere in them.

Ben

[Shmuel Metz]

In <bkbov8-...@anubis.morrow.me.uk>, on 02/01/2012
at 06:07 PM, Ben Morrow <b...@morrow.me.uk> said:

> <!-- padding for IE

I should have veen clearer; I don't do windoze, but if a newer version
of FF is going to do that then I want to know how to tell it to be
honest.

BTW, I refer to that sort of behavior as either "user fiendly" or as a
"Molly Malone", from "she died of a faever".

[Ben Morrow]

Quoth Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid>:

> In <bkbov8-...@anubis.morrow.me.uk>, on 02/01/2012
> at 06:07 PM, Ben Morrow <b...@morrow.me.uk> said:
>
> > <!-- padding for IE
>
> I should have veen clearer; I don't do windoze, but if a newer version
> of FF is going to do that then I want to know how to tell it to be
> honest.

[I've replied by private mail, since this is now completely OT for
clpmisc. The short answer is I was mistaken about FF's behaviour.]

Ben