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

[stew dean]

(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.

Not applicable.

2. Post a short sample script that demonstrates the
problem.

Not applicable - no errors - no sample script.

3. Ask for help in a CGI-related or IIS-related
newsgroup.

Only well into the debate. I'm suprised someone didnt pipe up 'read
the FAQ' then plonked me when I asked which FAQ.

4. Run the script from a command prompt so you can see
errors and warnings as they happen.

This is the bit of advice I followed and it worked, only after I got
shit for asking why I should use the command line.

5. use CGI::Carp qw(fatalsToBrowser warningsToBrowser);

No difference in output to normal.

6. see "perldoc -q 500"

This came up late in the discussion. It's essential RTFM. In this case
the manual is of no use. It did tell me I would have been better off
in a CGI newsgroup and you lot get a bit shirty around here - guess I
know that now. Some of you guys really need to chill out.

Think of it this way - if I never used the command line before (except
to install modules) then why would I know what perldoc means? I would
have used perl.org and like I did in this case and not have found the
answer as I get burried in unrelevent material.

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

Because the script outputs no errors in the browser. Using the command
line - as I've stated before, it gave me the errors. This allowed me
to fix the script. Now I want the errors that showed up in the command
line to display in the browser as at the moment I have to maintain two
scripts - one with relative links and one absolute. There is a
problem.

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.

Because most of the things suggested have not helped. Yes the headers
are correct, no there are no syntax errors, yes the files are inputing
and outputting correctly.

The problem WAS with the script but if I'd posted code up you wouldnt
have seen it without me supplying the XML file. I don't think anyone
here wanted a 40 page message.

I was after finding out how to get to my errors. After someone had
told me I'll get a list of errors by using the command line this is
what I did. And it worked. Until someone mentioned that I couldnt
follow the advice.

Some have their own ways of working and often it is suggested to use x
or y solution because that is how they do it - not because it will
give me any more answers. Now I know that the command line gives me
errors not seen in the browser - and I want these errors to show up in
the browser.

Stew Dean

 

[Tassilo v. Parseval]

Also sprach stew dean:

(e-mail address removed) (Jay Tilton) wrote in message news:<[email protected]>...

This came up late in the discussion. It's essential RTFM. In this case
the manual is of no use. It did tell me I would have been better off
in a CGI newsgroup and you lot get a bit shirty around here - guess I
know that now. Some of you guys really need to chill out.

Think of it this way - if I never used the command line before (except
to install modules) then why would I know what perldoc means? I would
have used perl.org and like I did in this case and not have found the
answer as I get burried in unrelevent material.

The command line is not the only way to get to the documentation.
http://www.perldoc.com/ comes to mind, for instance. What you write
implies that you haven't yet read the posting guidelines of this group
(posted regularly by Tad whom you titled an 'arsehole').

Had you lurked a while here (or at least read a couple of posts to this
group of the past weeks), you would have figured all that out yourself.
It's in general not a good idea to enter a new surrounding without
checking the local conventions.

Tassilo

 

[stew dean]

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



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.

Looked this up. There's some useful stuff here although it might make
my work more complicated if I used all it's features. The form related
handling is about the only bit I might use. Thanks for the suggestion.

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.

The code woudl have clouded the issue I feel - although it might have
helped to post my headers I use which, with the carp added, are...

#!/usr/bin/perl
use XML::Simple;
use strict;
use warnings;
use Time::Local;
use CGI::Carp qw(fatalsToBrowser);

I then have all the 'my' statements and a lot of code that does stuff
like...


open(SOURCEXML, "< $thexml") or die "can't open $thexml: $!";
open(TEMPORYXML, "> $tempxml") or die "can't open $tempxml:
$!";

# fix xml simple error with pound
while (<SOURCEXML>) {
s/\&pound\;/UKP/g;
(print TEMPORYXML $_) or die "can't write to $thexml: $!";
}

close(SOURCEXML) or die "can't close $thexml: $!";
close(TEMPORYXML) or die "can't close $tempxml: $!";

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.

Both the IIS and perl docs where crappy. This is what happens if you
have a weird set up I inherited. My problem is I'm using stuff I used
to use when I was working on unix boxes on a windows box - it's a
clash of cultures but I'm stuck with it. The previous 'tech' was
absolutely clueless (took him a year to set up a basic database
application that didnt really work).

I would love to have linux and apache etc but I'm stuck with a windows
box and I'm not in a position where I can have the down time to switch
from IIS to apache. This is a 24/7 live site and I can't reconfigure
it without some very very good reason. I also can't afford the
learning time to work out how to get everything I've set up for IIS to
work with apache. But I understand why you make the suggestion.

Stew Dean

 

[Kåre Olai Lindbach]

Looked this up. There's some useful stuff here although it might make
my work more complicated if I used all it's features. The form related
handling is about the only bit I might use. Thanks for the suggestion.

But there is also a lot of functionality in CGI.pm you don't see you
will also take advantage of. Ex. _correct_ POST and GET parsing.
Params that contains more than one scalar value etc etc. Just the
parsing and param-getting/setting is worth CGI.pm using.

You don't need to use all features. You might still do all HTML-code
by hand. Sometimes I _need_ to do it. It's the main CGI-protocol-part
you don't need to tingle with, unnecessary.

 

[Tintin]

ko <[email protected]> wrote in message

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.

Although the CGI module can generate HTML, the overwhelming reason people
use it is that it handles...wait for it....CGI.

 

[tom]

The code woudl have clouded the issue I feel - although it might have
helped to post my headers I use which, with the carp added, are...

#!/usr/bin/perl
use XML::Simple;
use strict;
use warnings;
use Time::Local;
use CGI::Carp qw(fatalsToBrowser);

Insert the following lines here:

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

I then have all the 'my' statements and a lot of code that does stuff
like...


open(SOURCEXML, "< $thexml") or die "can't open $thexml: $!";
open(TEMPORYXML, "> $tempxml") or die "can't open $tempxml:
$!";

Now when you run your script, you should see 'This is a test...' followed by
whatever your script output if any. If there any error messages generated, you
may find them in error.txt or your server error log.

Tom

 

[Jay Tilton]

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

: (e-mail address removed) (Jay Tilton) wrote in message : > 1. Look at the server's error log.
:
: Not applicable.

Why is that not applicable? The server's error log is where all
messages that would go to STDERR end up. Those pages of messages you
saw when running the program from the command prompt would be in the
error log.

If IIS has no error log, then it is an inexcusable obstacle to
productivity. Life is too short to use bad tools.

: > 4. Run the script from a command prompt so you can see
: > errors and warnings as they happen.
:
: This is the bit of advice I followed and it worked, only after I got
: shit for asking why I should use the command line.

That advice showed up early and it showed up often. By the time you
asked why, readers had become exasperated.

: > 6. see "perldoc -q 500"
:
: This came up late in the discussion. It's essential RTFM. In this case
: the manual is of no use.

The FAQ answer points to brian d foy's CGI "Troubleshooting Perl CGI
scripts" guide. That guide parrots much of the advice given in this
thread, but has additional discussion on the significance of each step.
Did you read it?

In Message-ID: <[email protected]>, you
mentioned,

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

We must not be looking at the same document. The only Unix-centricity
in brian's guide has to do with file permissions. The rest is
remarkably OS-generic.

: It did tell me I would have been better off
: in a CGI newsgroup and you lot get a bit shirty around here

Blame the technical mind for the shirtiness. The hacker enjoys a
challenge and loathes time-waste. The only challenge presented in this
thread was how to prod you into trying some basic diagnostic steps, and
that rapidly devolved into a perceived waste of time.

: guess I know that now. Some of you guys really need to chill out.

Past campaigns of clpm social reform have failed. You are free to
ignore those group participants you find abrasive, or you can seek help
in a gentler place.

: Think of it this way - if I never used the command line before (except
: to install modules) then why would I know what perldoc means?

You could have asked.

: > There's no evidence you've tried any of those things. Your only
: > response to each arsehole has been "the script works."
:
: Because the script outputs no errors in the browser.

That is typically true of any program, Perl or otherwise, that is run in
a CGI environment. The end-user doesn't need to be exposed to detailed
error and warning messages. The developer does need those messages, but
he has the server logs on his side.

: Using the command
: line - as I've stated before, it gave me the errors. This allowed me
: to fix the script. Now I want the errors that showed up in the command
: line to display in the browser as at the moment I have to maintain two
: scripts - one with relative links and one absolute. There is a
: problem.

That is what the error log is for. Find it and use it.

 

[ko]

stew dean wrote:

[snip]

Some have their own ways of working and often it is suggested to use x
or y solution because that is how they do it - not because it will
give me any more answers. Now I know that the command line gives me
errors not seen in the browser - and I want these errors to show up in
the browser.

I'm still not sure why you're so set against using the shell (not
asking/looking for an explanation) to see what's wrong with the script,
but try this:

use strict;
use warnings;

use CGI;
use CGI::Carp 'fatalsToBrowser';

my $cgi = CGI->new;
print $cgi->header;

# this is the new/relevant part
$SIG{__WARN__} = sub { print "$_<br />\n" foreach @_ };

print $cgi->start_html('test page');
my $test_string;
print $test_string;

print $cgi->end_html;
__END__

If you run the script from the shell, you'll get a 'Use of uninitialized
value in print...' warning. The '$SIG{__WARN__}' allows warnings to be
redirected to the browser.

And this is *really* ironic because the idea came from this post (long
link follows):

http://groups.google.com/[email protected]#link2

If for some strange reason the link doesn't work, guess who's the author
of above message?? Yes, its that 'arsehole' Tad Point being that
maybe you need to chill out - the time and energy spent antagonizing
people in the group would definitely be better spent on reading/scanning
all of the good advice that is available here. That post is only a
couple of days old...

keith

 

[stew dean]

Although the CGI module can generate HTML, the overwhelming reason people
use it is that it handles...wait for it....CGI.

Yep - been fiddling with it. It does this very well.

Stew Dean

 

[stew dean]

Here is one suggestion: you can input the root or base directory for
your relative paths using a command-line argument.

I really don't want to be flicking between command line and browser. I
know others don't understand this but all I want to do is run my
script without having to pass a lot of arguments using the command
line. Now maybe there's a way to emulate one script talking to
another. I personaly don't want to have to remember a string of 10
arguments (that's where I'm upto).

I want all the errors to show up in my browser or in an error log.
That's all I want now. I've been trying different solutions and so far
nothing has worked.

There's so many bits I'm not sure about - like does the STDERR include
everything you would see on the command line? Where does the STDERR go
and when is it written to? Is there a missing error log I can't see.

Thanks for taking the time to respond, it is appreciated.

Stew Dean

 

[stew dean]

Oh well, of course you have any right to write your programs blindfolded
with one hand tied to your back.

What exactly do you mean by that. Appart form seeing more errors why
do need to use the command line when it means twice as much work for
me?

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.

But by using the commmand line it feels like you want to bind my legs.

Perhaps there's something you're not telling me?

Stew Dean

 

[Ben Morrow]

I really don't want to be flicking between command line and browser. I
know others don't understand this but all I want to do is run my
script without having to pass a lot of arguments using the command
line. Now maybe there's a way to emulate one script talking to
another. I personaly don't want to have to remember a string of 10
arguments (that's where I'm upto).

The reason many people are recommending you start debugging your
script on the command line is that it takes out a whole layer of
complexity: once you are sure your script does what you think, any
remaining problems are with the interface between script and browser
via the server.

If you use CGI or CGI::Lite (which I would recommend if you write your
own HTML); you need make no modification to your program to be able to
simply pass a query string (the bit of an URL after the ?) on the
command line. If you use DOSKey, or a decent shell, you need only type
it once and then use history to run the same command many times.

There's so many bits I'm not sure about - like does the STDERR include
everything you would see on the command line?

No. As a general rule, command line apps spew both stdout (which under
CGI would go to the browser) and stderr (which should go to the log)
onto your terminal. If you use a real shell you can redirect either of
them independantly somewhere else; if you are stuck with DOS the best
you can do is send stdout to a file.

Where does the STDERR go and when is it written to? Is there a
missing error log I can't see.

That is a question about your web server... at least with Apache,
stderr is logged to error_log.

Ben

 

[Anno Siegel]

What exactly do you mean by that. Appart form seeing more errors why
do need to use the command line when it means twice as much work for
me?

If you use the CGI module your CGI script can be run from the command
line without any changes. That is one of the reasons the module is
recommended.

But by using the commmand line it feels like you want to bind my legs.

By using the command line, you eliminate a lot of complexity from
the situation. When a CGI script doesn't work *as a CGI* the problem
can be at three points:

- the environment the script is called in isn't what the script needs
or expects

- the script itself doesn't work to specification

- the script's output (diagnostic or otherwise) is treated in ways
you don't expect.

Working from the command line, you control every aspect of the environ-
ment, and output isn't post-processed. So you can concentrate on the
script itself. Once it does what it is supposed to do, you can put it
back in and concentrate on the other aspects.

If you change a light bulb and it doesn't light up, would you insist
in leaving it screwed in while trying to find out what's wrong?

Anno

 

[tom]

anno4000 - lublin.zrz.tu-berlin.de (Anno Siegel) wrote:
..
..

Working from the command line, you control every aspect of the environ-
ment, and output isn't post-processed. So you can concentrate on the
script itself. Once it does what it is supposed to do, you can put it
back in and concentrate on the other aspects.

If you change a light bulb and it doesn't light up, would you insist
in leaving it screwed in while trying to find out what's wrong?

Anno

I don’t see how one can control every aspect of the environment from the
command line. For example, if the script requires the values in cookies, these
values will only be available if the script was run from the browser. Also, it
is very common for CGI scripts to include JavaScript functions, which these
functions cannot run from the command line. Trouble shooting CGI scripts still
may best be handled by running from the browser.

That light bulb doesn’t light up could be a burnt out fuse, which you may not
want to simply replace it. Besides, the OP got his answer already. This thread
should now be closed.

Tom

 

[Alan J. Flavell]

I don’t see how one can control every aspect of the environment from the
command line.

Perhaps you would see it better if you were to read CGI.pm's
documentation about its debugging options.

Of course there's nothing magical in there: it's just a lot more
convenient and effective (in the vast majority of cases, anyway) to
work with CGI.pm than to set up the environment manually yourself and
then stumble through hand-written low-level code.

For example, if the script requires the values in cookies, these
values will only be available if the script was run from the browser.

Cookies aren't something magical either: in normal operation, the
server makes them available to the CGI script via the environment, and
your debugging session can just do the same.

Also, it is very common for CGI scripts to include JavaScript
functions,

It's not a very good idea for the operation of a system to depend
critically on the execution of javascript at the client.

But anyway, the proper way to design and debug a complex system is to
build it in manageable parts, and debug each part in a suitable
harness. Seems to me you should be debugging your client-side
javascript separately until it works - not tossing untested code into
what's already a complex system, which is, ex hypothesi, causing you
some kind of difficulty to debug.

Trouble shooting CGI scripts still
may best be handled by running from the browser.

The foregoing discussion suggests to me that you're in no position yet
to make that determination.

Besides, the OP got his answer already. This thread should now be
closed.

Hello, who appointed you netcop this week?

 

[Jürgen Exner]

Anno Siegel wrote:
[...]

By using the command line, you eliminate a lot of complexity from
the situation. When a CGI script doesn't work *as a CGI* the problem
can be at three points:

[three good points snipped]

On top of the partitioning of the complex CGI environment into independent
steps you also get all the benefits of a development environment for a real
programming language:
- you can use a debugger to pinpoint any problem
- you can use profiling and benchmarking
- instant test/bugfix/text cycle without uploading the script to some server
- etc. etc.

jue

 

[Jürgen Exner]

I don't see how one can control every aspect of the environment from
the command line.

Au contraire, mon ami! The command line is the only environment where you as
the programmer are the sole person who controls the environment. On a web
server too much depends upon how the server and how the server has been
configured by the server admin (which typically is not the same person as
the programmer of the script).

For example, if the script requires the values in
cookies, these values will only be available if the script was run
from the browser.

I certainly don't know much about CGI programming, but it is my
understanding that web servers use environment variables to pass cookie
values to CGI programs. What is the problem with setting those values before
running the script? You do it only once and you can even alter them very
easily to test different configurations and behaviours.

Also, it is very common for CGI scripts to include
JavaScript functions, which these functions cannot run from the
command line.

Hold it, hold it. Now you are talking about a different game.
By the time you start writing the Perl CGI script you better know exactly
what kind of HTML or JavaScript it is supposed to produce and you tested
that part already, using static files.

Trouble shooting CGI scripts still may best be handled
by running from the browser.

Of course at some point you have to put it all together and you will have to
test it as a whole.
But that should be at the very end when you are confident that the
individual pieces are working fine on their own.
If you do it earlier then you will be very confused about what causes a
problem, the Perl script, the JavaScript or HTML that the Perl script
generates, the server configuration, the web browser configuration, the web
browser itself, ....

jue

 

[A. Sinan Unur]

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

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

Everyone who has responded to you has been way more polite than your 'I'm
not going to lift a finger to help you help me solve my problem' attitude
deserved.

 

[Helgi Briem]

That is a question about your web server... at least with Apache,
stderr is logged to error_log.

While your advice is all correct and good, I strongly suggest
you stop responding to this troll who is clearly here only
to get a rise out of people by acting like a complete moron.