«

Dear Perl Gurus,

I have a slight situation involving transitioning a web site from one
host to another. The site has a number of Perlscript based
applications. It's a government website and 4 out of 5 applications
have been successfully transferred, which indicates that perlscript is
being understood on the new server - but getting this final
application up and running is, to use the vernacular, doing my head
in.

It could very well be an IIS situation (there is a transfer from IIS5
to IIS6 involved, also Win2000 to Win2003), in which case this would
not be the appropriate group to consult, but there are deadlines and
other ugly considerations so I'm wanting to cover my bases. Also, the
functions involved are rather embarrassingly basic, so I would be
surprised if it was a server issue - I've been bitten before by
reserved words I wasn't aware of so that's a possibility.

The problem is, in a nutshell, a perpetual syntax error. Normally you
might think this would be a misplaced semi-colon or something, but
this has proved not to be the case.

Here is a C&P of the exact error:
----------------
PerlScript Error error '80004005'

syntax error

/parentalleave/calculate/_private/common.inc, line 78
-------------------
Here, for the record, is line 78 of common.inc (surrounded by nearby
lines)
-------------------
"startworkdaterequired" => "Please enter the start work date",
"hoursworkederequired" => "Please enter the number of hours per
week worked",
(78 - parenthesis added for demo purposes)---> "badDOB" => "The
birth date or due date is invalid.",
"badstartworkdate" => "The start work date is invalid",
"badhoursworked" => "Please enter numbers only in the hours
worked field",
-------------------------

It's part of a basic hash declaration for error messages - there is no
wizardry occurring. Even if I comment out line 78 - I get the same
error on the same line - as if the file is being absorbed but not
understood at all and the parser is just giving up at that point It's
exactly the same files that previously worked on our prior hosts,
which can be observed at

http://www.ers.dol.govt.nz/parentall...ate/index.html

For reference purposes, here are the initial declarations:
-----------------------
<%
#common.inc
#Global variables and routines for the ERS Parental Leave
Entitlement Caclulators

use lib 'd:\inetpub\ers-production\bin\';
use strict;

use TWL::WebTools;
use Date::Calc qw(Date_to_Days Today Add_Delta_Days Month_to_Text
Today_and_Now Add_Delta_YMD);
--------------------------

Date::calc is the only additional module from the base Activestate
installation aside from some server based globals being declared in
TWL, and they are working fine in other applications. The inclusion
of Carp does not change the error message in the slightest Every
other .pm seems to be working as intended.

Originally, I was thinking that IIS was not comprehending .inc files,
but the same error persists even if files are renamed as .ASP or if
all the code is included on the one page.

I have been through the FAQ and ferreting through usenet history but
so far....nothing. I guess I'm looking for suggestions for other
walls to try banging my head against. It's been a couple of years
since I did any real Perl coding, so I'm guessing my Perl-fu is,
unfortunately, stoppable. Any suggestions would be more than
appreciated and if there is any more information which might assist
diagnosis, I am more than happy to provide.

Cheers,

-Giles

wrote:
> Here, for the record, is line 78 of common.inc (surrounded by nearby
> lines)
> -------------------
> "startworkdaterequired" => "Please enter the start work date",
> "hoursworkederequired" => "Please enter the number of hours per
> week worked",
> (78 - parenthesis added for demo purposes)---> "badDOB" => "The
> birth date or due date is invalid.",
> "badstartworkdate" => "The start work date is invalid",
> "badhoursworked" => "Please enter numbers only in the hours
> worked field",
> -------------------------
>
> It's part of a basic hash declaration for error messages - there is no
> wizardry occurring. Even if I comment out line 78 - I get the same
> error on the same line - as if the file is being absorbed but not
> understood at all and the parser is just giving up at that point It's
> exactly the same files that previously worked on our prior hosts,
> which can be observed at

What happens if you remove #78 altogether ans
duplicate #77 on #78

from:

"hoursworkederequired" => "Please enter the number of hours per week worked",
"badDOB" => "The birth date or due date is invalid.",

to

"hoursworkederequired" => "Please enter the number of hours per week worked",
"hoursworkederequired" => "Please enter the number of hours per week worked",

And, are you sure, #78 is the line YOU EXPECT it would be?
Put in some obvious error *before* and look what line
number is reported by the PerlScript interpreter.

Regards

M.

On Feb 26, 11:46 am, Mirco Wahab <wahab-m...@gmx.de> wrote:

>
> What happens if you remove #78 altogether ans
> duplicate #77 on #78
>
> from:
>
> "hoursworkederequired" => "Please enter the number of hours per week worked",
> "badDOB" => "The birth date or due date is invalid.",
>
> to
>
> "hoursworkederequired" => "Please enter the number of hours per week worked",
> "hoursworkederequired" => "Please enter the number of hours per week worked",
>
> And, are you sure, #78 is the line YOU EXPECT it would be?
> Put in some obvious error *before* and look what line
> number is reported by the PerlScript interpreter.
>
> Regards
>
> M.

If I put in a obvious error such as:

a;sfajf;asjf;alj;

in the first line I get the same Syntax error for the same line
(though plus one because of the extra line).
Replacing lines with other, previous lines doesn't seem to change
anything - same error, same place. If I comment out the specific Hash
declaration , it just produces the same syntax error later on. If I
comment out or remove just that line, I get the same syntax error on
the same line number.



This is making me think along the lines of an interpretation
difficulty/limitation - as in it's throwing in the towel because it's
got a a certain point and won't accept any more garbage, rather than
there being something specifically wrong with the code, which clearly
works on the prior server. Which just seems odd, as there are other
applications of greater length and complexity on the same site working
as intended.

I have been careful while transferring the files to make sure they are
untouched by errant text editors and their tricksy hidden characters -
so I am fairly sure what is working on the initial site is the same as
the code on the new site - hence my foncusion. I realise the platform
is not exactly the same, but don't know what kind of factors might be
creating such a situation. It's definitely finding the included page,
but just doesn't appear to be processing/interpreting it before it
gives up (and, again, the same thing (syntax error) happens if all
the code is placed in the page itself).

Thanks for your assistance It's much appreciated.

Cheers,

-Giles

wrote:
> Even if I comment out line 78 - I get the same
> error on the same line - as if the file is being absorbed but not
> understood at all and the parser is just giving up at that point

Look for mis-matched or missing quotes in an earlier line. Something like:

$some_var = "a string';

It's just a guess, but I've seen this sort of thing before.

Try removing line 78, and see if the error message changes. That should
give you an idea where to look.

On Feb 26, 1:59 pm, Scott Bryce <sbr...@scottbryce.com> wrote:
> gbou...@paradise.net.nz wrote:
> > Even if I comment out line 78 - I get the same
> > error on the same line - as if the file is being absorbed but not
> > understood at all and the parser is just giving up at that point
>
> Look for mis-matched or missing quotes in an earlier line. Something like:
>
> $some_var = "a string';
>
> It's just a guess, but I've seen this sort of thing before.
>
> Try removing line 78, and see if the error message changes. That should
> give you an idea where to look.

This proved to be prescient - only it wasn't quite as obvious as
that. The line was $some_var = "a string wit' an apostrophe, ending
with a double quote"; which was being misinterpreted owing to a prior
error. By escaping the single quote, we found another in a commented
out line! Escaping that also we iterated through as the chain of
error messages got much more helpful and finally progress was being
made. I'm still not sure why it only affected the new site and not
the other code - different Activestate versions perhaps? Character
set on servers?

Anyhow - thanks for the replies

-Giles