Perl and IIS - script runs but 'The page cannot be displayed'

K

Kåre Olai Lindbach

It's to do with the way perl is running on IIS - that is for some
reason it is running but the output is not reaching the browser.

It's also about finding out more about how Perl runs on windows.

Perl doesnt naturaly have an error log on windows from what I can see
and so far I have been relying on the errors given to me in the
headers returned -that is the usualy syntax and other errors that are
returned by using strict.

Now I'm exploring all the other suggestions but so far I've had not
joy.

(I think you are wining alot, and putting yourself more and more into
a corner. It is often better to listen to the advices, think, and
rephrase questions and summerize that you have tried in a systematic
and quiet/calm way. If you start answering all inputs, and starts
making new unnecessary ones, as you have done, you will end up just
discussing nonsense. I was just at the edge of plonking you :).

I have some years experience (> 6) with MSwin32 and MS-IIS in
different environments, especially using CGI. I always use CGI::CARP
qw(fatalsToBrowser warningsToBrowser) during testing, besides those
obvious let-perl-help-you things. I also test syntaxt through my Emacs
shell as "perl -c <perl-script>", and often also run them, and watch
the raw output..

What I have experienced when running large output to browser from
MS-IIS, compared to small output, is that if it contains undefined
fields, it woun't show anything, not even an error, just time out.
Maybe that's your problem?

Also you might get timed-out if the output takes considerable longer
time to output. Then you need to send something to keep-alive, or use
other methods. Are you sure your big-scripts algorithm isn't so that
it takes considerably longer time to run, than a small one?

As I have understood, you are able to run small scripts correctly?!
 
T

tom

jwillmore said:
Hum ... are you outputing the correct HTTP header? Maybe there _is_
something wrong with the script? A typo, maybe? Running the script
_at the command line_ will produce messages that _may_ not be seen as
errors, but as warnings that the web server is just dismissing. You
can also see what the script is sending out to the browser. What ever
you see at the command line is what _should_ be going to the browser.

Try to include the following at the beginning of your script:

print "Content-Type: text/html\n\nThis is a test...";
open(STDERR,"> error.txt") or die $!; # capture any standarn error outputs
for my $ix(0..5000) { print " " } # force the browser to flush the buffer

"This is a test..." should be displayed and any error messages may be found in
error.txt

Tom
 
K

ko

stew said:
(e-mail address removed) (James Willmore) wrote:
What happened when you ran the script at the command line?
I've never run a perl script at the command line.

Because I've never had to. Why would I want to?
[snip]

If I run it from the command line it can't find the input file as the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this is probably important and shouldn't be ignored, see below...
file is relative to the web server. This is all about reading and
writing files afterall.

Wow, you have managed to ignore James Willmore's advice and (I think)
answer your own question in one stroke :) When you read/write files you
need to be specific(physical vs. relative path) - the fact that its a
CGI script is irrelevant. And since this the problem *seems* to be
related to reading and writing files, try the following:

use strict;
use warnings;

use CGI;
# use CGI::Carp 'fatalsToBrowser';
my $cgi = CGI->new;
print $cgi->header, $cgi->start_html('test page');

print $cgi->p('blah blah blah');

# open(FH, 'c:/NONEXISTENT_TEXT_FILE') or die $!;
# print while (<FH>);
# close(FH) or die $!;

open(FH, 'c:/FILE') or die $!; # make sure 'FILE' exists!!
print while (<FH>);
close(FH) or die $!;
__END__

First, run the script as is and make sure that you substitute 'c:/FILE'
with a file that exists on your system using the *full/absolute* path -
the 'blah blah blah' is displayed as are the file contents.

Second, uncomment the three lines from where you try to open
'c:/NONEXISTENT_TEXT_FILE' (assuming the file doesn't actually exist).
The 'blah blah blah' is displayed, which could lead you to think that
the script is working, but the contents of the file that does exist are
not. This simulates what happened when you ran your script from the
command line - couldn't open the file.

Do you see what's happening? No *syntax* error, but everything *after*
the first open() is ignored because the script dies. Actually, even if
you don't bother to check the return value of open(), everything would
still be ignored. I would guess the 'Done! message/page that referred to
in your original post comes after your attempts to read/write the XML
file(s)?

[snip]
If something is broke it gives me the error by passing me the
headers. Will Carp give me any errors that I don't already receive
(given that I'm not adding debug messages into the script)?

Yes, it would have been easier just to do it this way. Uncomment the
'use CGI::Carp 'fatalsToBrowser';' line and see what happens.

Even if this doesn't exactly solve your problem hopefully, at least, you
can see how valuable running your script from the command line and
CGI::Carp are.

You probably could have spared yourself a lot of grief if you had posted
some code. And, more unfortunately, you have managed to alienate a lot
of people in the group who could provide you with a lot of *good* advice
- that's too bad :(

HTH - keith
 
J

James Willmore

On 23 Oct 2003 02:22:26 -0700
Because I've never had to. Why would I want to?

[Sigh]

Because it _may_ give you a clue as to why you're not getting what you
want from the script. It's not a perfect solution, but it is a
healthy place to start. After all, the CGI can be considered a
server's STDIN, right?

All errors that are generated by the script are displayed in the
output. It uses strict so all errors are picked up including
variables not declared. If it finds more than one it stops running
and tells me.

Now there may be errors produced of a different kind but then this
would be new to me and I'm trying to find out what kind of errors
they may be. The code it's self is fine with no syntax errors.

If I run it from the command line it can't find the input file as
the file is relative to the web server. This is all about reading
and writing files afterall.

Yes, I understand. Using the '-debug' switch for the CGI module will
allow you to run the script, from the command line, and allow you to
see what the script's output (the good, bad, and ugly) is. Using this
switch will allow you to send parameters to the script as if the
script is getting them through the CGI (aka the web server's STDIN).
So, if you are passing a file name as a param to the script, you can
type that in while running the script on the command line. I know all
this because I've done it :)
If something is broke it gives me the error by passing me the
headers. Will Carp give me any errors that I don't already receive
(given that I'm not adding debug messages into the script)?

Yes. Read the documentation for CGI::Carp for other settings for the
module. It's rather robust and very useful for debugging CGI scripts.
The one caveat is _don't_ use it in a production environment. The
messages that can be created and used in development can be considered
a security risk in a production environment.

I've tried to make the effort to lend a hand to you in this task. I
know it may not seem like it. Consider the message, not the way the
message is being delivered and it, I hope, will appear that I have
made the effort. However, unless you can offer new information about
what's going on, I suggest you post to a CGI authoring group. There,
the group can offer assistance in configuration of IIS and all the
issues associated with IIS. I have 'zero' experience with IIS, but
lots with Perl and using it through the CGI. If this issue is IIS
related,
I can't offer anything more.

Good luck.

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
I really hate this damned machine I wish that they would sell it.
It never does quite what I want But only what I tell it.
 
J

Jürgen Exner

stew said:
It's to do with the way perl is running on IIS -

I see. But at least to me this appears to be a question about IIS, not about
the programming language Perl.
Did you ask in a newsgroup that actually cares about IIS? It would be a mere
coincidence if someone in a Perl related newsgroup would know about IIS.
that is for some
reason it is running but the output is not reaching the browser.

And the programming language Perl has even less to do with 'browsers'.
Again, this seems to be a problem with IIS, not with Perl.
It's also about finding out more about how Perl runs on windows.

Fair enough. The easiest way is probably to go to activestate.com and
install their pre-compiled ActivePerl.
Perl doesnt naturaly have an error log on windows from what I can see

Well, do compilers for C or Haskell produce code that generates error logs?
Or do interpreters for Basic or Prolog or ... generate error logs? Not that
I am aware of. Typically any error message is sent to STDERR. Perl is in no
way different.
and so far I have been relying on the errors given to me in the
headers returned -that is the usualy syntax and other errors that are
returned by using strict.

Well, once you've installed ActivePerl you may want to check "perldoc -q
500". It might be an eye opener.

jue
 
J

Jürgen Exner

stew said:
There is no error from perl - that's my problem.

Then the chances that your problem is related to Perl are minimal.

Before waisting your time investigating most-likely-non-existing Perl
problems I strongly suggest you look into the other areas like the code
your script generates, IIS configuration, etc.
Chances are the root of your problem is there.

At this point the only way that you could convince me that it is a Perl
problem indeed would be if the problem does not happen if you write your
program in C or Prolog or any other programming language.

jue
 
S

stew dean

Alan J. Flavell said:
I was responding specifically to the current issues. I saw no reason
to rake-over past acrimony.


I'm one who's saying that the web has now finally caught up with the
recognition that HTML would better not be used for layout. The idea
of using stylesheets pre-dated RFC1866/HTML2.0, and it should have
been obvious to anyone who bothered to rub two brain cells together
that they were a good approach. It's taken too long to get there, but
it's finally happening, and I find that development rather positive.

I think I remember us agreeing on style sheets. If you go back you'll
see many of the things I predicted did indeed come true. The way style
sheets where adopted played out as I described - it was dependent on
adoption by browsers and by those who have made a living from the web,
people like myself.

Style sheets now mean HTML is used for detailed layout. It now
includes pixel level positioning and point sizes. It also allows a
greater amount of what I have preached for many years - pages that
degrade gracefully.


But it is, and has been for over seven years. Where have you been?

Stew Dean
 
H

Helgi Briem

Well, once you've installed ActivePerl you may want to check
"perldoc -q 500". It might be an eye opener.

Finally somebody put the poor sod out of his misery
and threw him a titbit that will actually help.

I think this "off-topic newbie baiting" sometimes
gets a little out of hand.

At least start with "perldoc -q 500" when one of these
clueless people arrives here each week. I mean, he
shouldn't have to read 30 posts before he gets told
to RTFM.
 
H

Helgi Briem

Because I've never had to. Why would I want to?

I've been hovering over whether to killfile you for
cluelessness or not. You have removed all doubt.

<PLONK>
 
E

Eric Bohlman

(e-mail address removed) (stew dean) wrote in

Are you sure about that? Have you actually *seen* the correct HTTP header
being output? Or do you mean "I've written the code to output the correct
HTTP header"? Between those two concepts lies a space that's often
inhabited by a guy named Murphy.
 
S

stew dean

Helgi Briem said:
I've been hovering over whether to killfile you for
cluelessness or not. You have removed all doubt.

Oi idiot - why didnt you answer the question?

You don't need to use the command line to write perl scripts. If all
the errors I needed appeared in the browser I would never ever have to
go near the command line to write perl.

There are some real arrogant arseholes around here.

Stew Dean
 
S

stew dean

Helgi Briem said:
Finally somebody put the poor sod out of his misery
and threw him a titbit that will actually help.

It wasnt useful. It took me to a document that was for unix users.

You ever read 'The Hitchhikers Guide' - well this is the you version
of the plans for the new bypass. perldoc -q 500 is the equivalent of
'beware of the leopard'.
I think this "off-topic newbie baiting" sometimes
gets a little out of hand.

At least start with "perldoc -q 500" when one of these
clueless people arrives here each week. I mean, he
shouldn't have to read 30 posts before he gets told
to RTFM.

The manual ain't no good. Why do you think I'm asking!!

Stew Dean
 
S

stew dean

James Willmore said:
On 23 Oct 2003 02:22:26 -0700
Because I've never had to. Why would I want to?

[Sigh]

Because it _may_ give you a clue as to why you're not getting what you
want from the script. It's not a perfect solution, but it is a
healthy place to start. After all, the CGI can be considered a
server's STDIN, right?

And lo - it did!

But to do this I had to turn all my reletive paths to absolute and
hard code in the variables passed to the script. All very messy but it
turns out you are right - it gives out error messages as if it's
writing to an error log. As someone pointed out there is not error log
otherwise.

The errors pointed out problems with the perls script. The perl script
was to blame. It was over 20 pages long and wouldnt have made any
sense without the XML file - the reason I didnt post any code.

Yes, I understand. Using the '-debug' switch for the CGI module will
allow you to run the script, from the command line, and allow you to
see what the script's output (the good, bad, and ugly) is.

You'll have to explain this. What is the CGI module? I've seen
reference to use CGI.pm but havnt had a reason to use it so far.
Using this
switch will allow you to send parameters to the script as if the
script is getting them through the CGI (aka the web server's STDIN).

Okay but what I really want to do is not have to use the command line
and instead get all the errors in the browser.
So, if you are passing a file name as a param to the script, you can
type that in while running the script on the command line. I know all
this because I've done it :)

Cool - but I first had to create a new version with absolute paths
before it run. Is there a way to avoid having to do this?

Yes. Read the documentation for CGI::Carp for other settings for the
module. It's rather robust and very useful for debugging CGI scripts.

Again - very cool. We're getting somewhere. Looks like I'm hunting
down where STDERR goes.

But I'm still confused. One of the errors I was getting was because of
UT8F characters - it was complainin about wide characters. How do
errors like this get displayed in the browser? The carp FAQ doesnt
appear to cover this.
The one caveat is _don't_ use it in a production environment. The
messages that can be created and used in development can be considered
a security risk in a production environment.

Sorry - what do you mean by 'production environment' - you mean live
rather than hidden for developement right?

I've tried to make the effort to lend a hand to you in this task. I
know it may not seem like it. Consider the message, not the way the
message is being delivered and it, I hope, will appear that I have
made the effort.

I truely appreciate your effort. I can take a bit if chest beating if
get some useful answers. Some folks here think they are giving the
correct answers but have gotten it as wrong as I have.
However, unless you can offer new information about
what's going on, I suggest you post to a CGI authoring group. There,
the group can offer assistance in configuration of IIS and all the
issues associated with IIS. I have 'zero' experience with IIS, but
lots with Perl and using it through the CGI. If this issue is IIS
related,
I can't offer anything more.

Well it turns out it's not IIS related but related to how I use perl
on windows. Some like to use command lines, for the reasons I've
stated it's easier to try and get the errors into the browser (or CGI
if you prefer).

As someone who only does perl when they need to and is used to using
usenet to find answers for other things I do find it unsettling that
you have to know a lot before you can post here - but that knowledge
has nothing to do with perl but where to find documents that don't
answer my question.

Like I said elsewhere - there's no point telling people to RTFM if
they don't know which manual or when they do read it its of zero help.

If you could help me avoid having to have two scripts and get the none
syntax related errors (like wide character warnings and the such)
displaying whe I call up the script via CGI this would be a great
help.

Cheers

stew dean
 
J

Jay Tilton

(e-mail address removed) (stew dean) wrote:

: > On 23 Oct 2003 02:22:26 -0700, (e-mail address removed) (stew
: > dean) wrote:
: >
: > >> > I've never run a perl script at the command line.
: > >>
: > >> Why not?
: > >
: > >Because I've never had to. Why would I want to?
: >
: > I've been hovering over whether to killfile you for
: > cluelessness or not. You have removed all doubt.
:
: Oi idiot - why didnt you answer the question?

Probably because you've demonstrated remarkable obstinacy in taking
advice. Talking to a wall gets old fast.

: You don't need to use the command line to write perl scripts. If all
: the errors I needed appeared in the browser I would never ever have to
: go near the command line to write perl.

Isn't the root of the problem that nothing at all is being displayed in
the browser?

: There are some real arrogant arseholes around here.

Problem diagnosis is a process, and so far you have refused to
participate in the process. You seem to want somebody to magically know
what's wrong and say "this is the problem, here is how to fix it."

The arseholes have been sharing solid advice on how to find where the
difficulty lies, often repeating what others have already said.
Here's a recap of those advices:

1. Look at the server's error log.
2. Post a short sample script that demonstrates the
problem.
3. Ask for help in a CGI-related or IIS-related
newsgroup.
4. Run the script from a command prompt so you can see
errors and warnings as they happen.
5. use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
6. see "perldoc -q 500"

There's no evidence you've tried any of those things. Your only
response to each arsehole has been "the script works."

Until you get past the assumption that there's nothing wrong with the
program and start trying some of the things people have suggested, there
is nothing left to do.
 
S

stew dean

ko said:
stew said:
(e-mail address removed) (James Willmore) wrote:
What happened when you ran the script at the command line?
I've never run a perl script at the command line.

Because I've never had to. Why would I want to?
[snip]

If I run it from the command line it can't find the input file as the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this is probably important and shouldn't be ignored, see below...
file is relative to the web server. This is all about reading and
writing files afterall.

Wow, you have managed to ignore James Willmore's advice and (I think)
answer your own question in one stroke :) When you read/write files you
need to be specific(physical vs. relative path) - the fact that its a
CGI script is irrelevant. And since this the problem *seems* to be
related to reading and writing files, try the following:

use strict;

I use this.
use warnings;

This I'm looking into as it might answer my question....

Don't use this as I write all my HTML by hand instead - just a person
choice thing. If it does anything more than write HTML please correct
me.

<rest of excellent examples snipped>

First thanks for replying in great depth. You post indirectly lead to
me solving my problem.

To get my script to work in the command line I created a new version -
one with the variables passed to the script hard coded (although there
are ways of doing it via the command line I've been informed) and also
with absolute paths rather the relative ones the server doesnt mind.

It gave me a whole new set of errors before spitting out my HTML (all
present and correct). These errors that I didnt see via the browser
once fixed resulted in the end HTML being displayed when run via the
browser.

The mistakes in the perl where not syntax but warnings of wide
characters and errors where an array memeber was called up that wasnt
defined (like, in one example the eighth day in the week).

So thanks for taking the time as your post, although not dead on
target, did lead to me solving the problem. Now I'm looking for a way
to avoid using the command line again (except to install modules etc)
so I only need one script.

Juding from some responces I've got (some have been downright nasty)
this may be better in the cgi group but cheers anyway.

Stew Dean
 
K

Keith Keller

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If you leave then there will be one less.

One fewer?

- --$arseholes;

Anyway, stew asked about CGI: the long answer is to perldoc CGI. The
short answer is that CGI helps immeasurably in parsing query strings and
POST parameters, and if you're not using it you're almost surely missing
something that'll bite you in the behind sooner or later.

stew also complained that people complained that he didn't post any Perl
code. The typical troubleshooting strategy in this situation is to
write minimal code that replicates the problem and post that. I don't
see where you ever thought about trying that, but it would likely help
in solving both your technical and social problems. :)

Finally, it seems like a lot of the original problem can be traced back
to crappy IIS docs. I'd suggest switching to a less crappy web server,
like apache.

- --keith

- --
(e-mail address removed)-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj+aFFoACgkQhVcNCxZ5ID9oUgCdGfZmieVOEwBIeWaNO2yqeIJp
F2EAoJCVLJ24ws8W4rMClzOOy6LmkTQA
=i1qi
-----END PGP SIGNATURE-----
 
J

Jürgen Exner

stew said:
Now I'm looking for a way
to avoid using the command line again (except to install modules etc)
so I only need one script.

Oh well, of course you have any right to write your programs blindfolded
with one hand tied to your back.
But then at least neither cry for help if you can't see the bugs because of
your blindfold nor offend those people who are telling you how to untie your
hands.

jue
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,764
Messages
2,569,564
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top