New to CGI

[Mark Adams]

(Mandrake Linux 9.2, Apache 2.0.47, Perl 5.8.1)

I cobbled together a page for my LAN that looks pretty good and I've got
a couple of CGI scripts on it that I like. They work well on this page.
I'm trying to upgrade the page to a better looking format using CSS
(I'm also new to CSS). The CGI are nothing terribly elaborate, an event
calendar and a link to news headlines on the Web.

At any rate, the Perl CGI that works well on the original page isn't
working at all on the new page. I'm not finding a lot on the WWW about
troubleshooting CGI. What can cause these scripts to fail with no error
(nothing appears on the page)?
--
Mark E. Adams, 2004 -- drop the "dot" to email me.

CONSIDER: ===========---------,,,,,,,,,............. . . . . .
Michelle: When we get back to the hole we are going to have a long
boring talk about our relationship.

 

[Toby Inkster]

At any rate, the Perl CGI that works well on the original page isn't
working at all on the new page. I'm not finding a lot on the WWW about
troubleshooting CGI. What can cause these scripts to fail with no error
(nothing appears on the page)?

Try running it at the command line. It's easiest if your script takes its
data from GET rather than POST or cookies. Then you can simply set the
QUERY_STRING environment variable and any other CGI variables that your
script requires and run it at the command line and see what happens.

 

[Mark Adams]

(Mandrake Linux 9.2, Apache 2.0.47, Perl 5.8.1)

I cobbled together a page for my LAN that looks pretty good and I've got
a couple of CGI scripts on it that I like. They work well on this page.
I'm trying to upgrade the page to a better looking format using CSS
(I'm also new to CSS). The CGI are nothing terribly elaborate, an event
calendar and a link to news headlines on the Web.

At any rate, the Perl CGI that works well on the original page isn't
working at all on the new page. I'm not finding a lot on the WWW about
troubleshooting CGI. What can cause these scripts to fail with no error
(nothing appears on the page)?

I guess I should include a snippet of the code in question:

========================<snip!>
<div class="story">
<table summary="" cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr valign="top">
<td class="storyLeft">
<p> <a href="#" class="capsule">Entertainment Stories</a>
<!--#include virtual="/cgi-bin/newsheadlines.cgi?top"--></p>
</td>
<td>
<p> <a href="#" class="capsule">Entertainment Stories</a>
<!--#include virtual="../../cgi-bin/newsheadlines.cgi?top"-->
</p>
etc., etc., etc.
========================<snip!>

Notice I am trying both "/cgi-bin" and "../../cgi-bin". The tree looks
like this:

/var/www/
|
/html/
| |
| /myhompage <--Test version of page resides here.
|
/cgi-bin

I've placed a copy of this page in /var/www/html and fiddled with the
path to /cgi-bin/ but it makes no difference.

There you go.
--
Mark E. Adams, 2004 -- drop the "dot" to email me.

CONSIDER: ===========---------,,,,,,,,,............. . . . . .
Pickle's Law:
If Congress must do a painful thing,
the thing must be done in an odd-number year.

 

[Mark Adams]

Try running it at the command line. It's easiest if your script takes its
data from GET rather than POST or cookies. Then you can simply set the
QUERY_STRING environment variable and any other CGI variables that your
script requires and run it at the command line and see what happens.

Running "../cgi-bin/newsheadlines.cgi" from the CLI at /var/www/html
works just fine. It also works just fine from my plain-Jane index.html
file. Heres is a snippet:

==================<snip>
<table cellpadding="4" cellspacing="2" border="2" width="797">
<tr><td>
TOP<!--#include virtual="/cgi-bin/newsheadlines.cgi?top"-->
</td><td>
ENTERTAINMENT<!--#include
virtual="/cgi-bin/newsheadlines.cgi?entertainment"-->
</td></tr>
<tr><td>
WORLD<!--#include virtual="/cgi-bin/newsheadlines.cgi?world"-->
</td><td>
TECHNOLOGY<!--#include virtual="/cgi-bin/newsheadlines.cgi?technology"-->
</td></tr>
</table>
===================<snip>

As an experiment, I composed a simple page in the /html folder:

================<snip>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>news.shtml</title>
</head>
<body>
WORLD<!--#include virtual="../cgi-bin/newsheadlines.cgi?world"-->
TECHNOLOGY<!--#include virtual="/cgi-bin/newsheadlines.cgi?technology"-->
</body>
</html>
====================<snip>

One of these links should work since the page is in the same folder as
the index.shtml page that works (see above), and there isn't any extra
stuff in the way. However, it does not work. :-\

--
Mark E. Adams, 2004 -- drop the "dot" to email me.

CONSIDER: ===========---------,,,,,,,,,............. . . . . .
My mother drinks to forget she drinks.
-- Crazy Jimmy

 

[Mark Adams]

Mark Adams wrote:




Try running it at the command line. It's easiest if your script takes its
data from GET rather than POST or cookies. Then you can simply set the
QUERY_STRING environment variable and any other CGI variables that your
script requires and run it at the command line and see what happens.

Once again, I solved it by adding an .htaccess file to a directory that
previously worked fine without one.

This is whacky. I'm sure there is a reason for all of it, but I don't
see what it is. I added the .htaccess file and just for good measure I
edited it to include the "option +Includes" and "AddType text/html
..shtml, AddHandler server-parsed .shtml" statements.

Now <!--#include virtual="/cgi-bin/newsheadlines.cgi?top"--> works just
fine.
--
Mark E. Adams, 2004 -- drop the "dot" to email me.

CONSIDER: ===========---------,,,,,,,,,............. . . . . .
BOFH excuse #171:

NOTICE: alloc: /dev/null: filesystem full

 

[Jeff Thies]

Although this probably wouldn't have helped in this particular case,
this line:

use CGI::Carp 'fatalsToBrowser';

will send most errors to the browser. Perl error messages are usually
wonderfully explicit.

Jeff

 

[Mark Adams]

Although this probably wouldn't have helped in this particular case,
this line:

use CGI::Carp 'fatalsToBrowser';

will send most errors to the browser. Perl error messages are usually
wonderfully explicit.

Jeff

That line should go in .htacces? It looks like a handy thing. I would
like to implement it.

Thanks.
--
Mark E. Adams, 2004 -- drop the "dot" to email me.

CONSIDER: ===========---------,,,,,,,,,............. . . . . .
sushi, n.:
When that-which-may-still-be-alive is put on top of rice and
strapped on with electrical tape.

 

[Toby Inkster]

That line should go in .htacces?

No, it shouldn't.

It should be the line after your "#!/usr/bin/perl" as part of your CGI
script.

 

[Art Sackett]

That line should go in .htacces? It looks like a handy thing. I would
like to implement it.

Keep in mind that you don't want to leave fatalsToBrowser in place once
you fully deploy. There are two downsides:

1. The whole world can see your error messages, which might give hints
about exploitable bugs.
2. It adds processing overhead to every invocation.

Only use it while debugging/testing, then comment it out.

If you want to avoid lots of bugs in the first place, always use the
'strict' pragma during development -- and again, comment it out when
you release for deployment.