perl syntax check

Discussion in 'Perl Misc' started by Helmut Richter, Jan 20, 2012.

  1. 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
    Helmut Richter, Jan 20, 2012
    #1
    1. Advertising

  2. Helmut Richter

    Tim McDaniel Guest

    In article <>,
    Ben Morrow <> wrote:
    >
    >Quoth 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.

    >
    >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,
    Tim McDaniel, Jan 20, 2012
    #2
    1. Advertising

  3. 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
    Helmut Richter, Jan 20, 2012
    #3
  4. Helmut Richter

    Willem Guest

    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
    Willem, Jan 20, 2012
    #4
  5. Helmut Richter

    David Combs Guest

    In article <>,
    Willem <> 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
    David Combs, Jan 31, 2012
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. gabriele renzi
    Replies:
    2
    Views:
    202
    gabriele renzi
    Dec 31, 2005
  2. Ken Bloom
    Replies:
    3
    Views:
    206
  3. Good Night Moon
    Replies:
    9
    Views:
    280
    Rick DeNatale
    Jul 25, 2007
  4. Replies:
    0
    Views:
    142
  5. sonet
    Replies:
    6
    Views:
    181
    J├╝rgen Exner
    Jun 17, 2007
Loading...

Share This Page