kevin has asked for the wisdom of the Perl Monks concerning the following question:

I worte some cgi scripts with Perl on my home PC: Win2k Professional, Perl 5.8.6 and MySQL 4.1.13. When I uploaded these to my website, they didn't work. Here's one script, dumbed doen to the point where its just a "Hello World" type of thing with some cgi afterwards:

#!/usr/bin/perl use strict; use DBI; use CGI qw(:standard); use CGI::Carp "fatalsToBrowser"; my $dbh = DBI->connect("dbi:mysql:database=dbname;host=localhost", "uname", "pword") or die "Unable to connect to DB: $DBI::errstr"; $dbh->disconnect(); print header, start_html(-title=>'Title', -BGCOLOR=>'blue', -text=>'white'), p('test'), end_html;

My web hosting service uses Perl 5.8.4 and MySQL 5.0.18.

Running this script via Firefox yields a blank white page; clicking "View Source" bring up a completely blank window. In IE, I get a "Cannot find server/this page cannot be displayed" error. Nothing shows up in the error log. If I remove the "dbh->connect" line, the page functions properly.

Even if I've mucked up the connection string somehow, shouldn't any error be posted to the browser via fatalsToBrowser? I am getting no feedback on what might be going wrong, and I am stumped.

Help!

Kevin

Replies are listed 'Best First'.
Re: dbh connections: stumped!
by jfroebe (Parson) on Mar 11, 2006 at 16:54 UTC

    IIRC, the use CGI::Carp "fatalsToBrowser"; is highly dependent on how the webserver is configured to handle errors. By default a 500 error is returned by the webserver to your browser. It is possible that the webserver is trapping the errors and presenting an empty page as a security measure (for production this isn't all that unusual).

    Along with the suggestions made already, I would contact your web hosting service and ask how the errors are handled. Perhaps they have a recommendation with respect to obtaining the errors. I suspect that you will have to trap the errors in your code yourself.

    Jason L. Froebe

    Team Sybase member

    No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Re: dbh connections: stumped!
by graff (Chancellor) on Mar 11, 2006 at 17:08 UTC
    Having written the script on a windows box, if you uploaded it to a unix or linux server, there is probably a problem on the shebang line, if the dos-specific CRLF line termination was not converted to unix LF. If the first line of your script (as it exists on the server) contains:
    #!/usr/bin/perl\r\n
    it won't run on the server. Get rid of the CR (use text-mode file transfer to the server, or dos2unix on the server after the script is uploaded.) Another work-around is to add a useful flag or two:
    #!/usr/bin/perl -T -w
    When you do that, you not only get the benefits of taint checking and warnings enabled (which you ought to do anyway for a cgi script!!), but also unix will correctly parse out the path to perl as /usr/bin/perl (rather than /usr/bin/perl\r).
      OK, thanks very much for the help so far. I've implemented most of these suggestions, but the problem persists.

      1. I've stopped using CGI and "fatalsToBrowser".
      2. I've eliminate the "die" portion of the connect string.
      3. I contacted my web hosting provider, but got a terse "we don't debug code" type of reply.
      4. I re-uploaded the code after running dos2unix.

      Some more info: the connection line is

      my $dbh = DBI->connect('dbi:mysql:database=<i>dbname</i>;host=localhos +t','<i>uname</i>','<i>pword</i>');
      If I mangle the first argument, I get a "Can't connect to database" error, just like I should. If I mangle either of the other two arguments, I get the same results as in my original message, a blank Firefox document or a "This page cannot be displayed" IE error. This time, however, the following lines appear in my error log (the Apache error log):
      Use of uninitialized value in split at usr/local/lib/perl/5.8.4/Apache +.pm line 172.
      Stil stumped, but again, thanks for the help so far. Kevin
        localhost? On a remote host? My ISP has given me an IP address to use there. I would check with the ISP for the correct connection details.

        Best of luck.

        wfsp

        You haven't mentioned whether you have shell access on that server. If you did, you might be able to try out the mysql command on a command line, confirm that your connection parameters work that way at least, and generally poke around in your database account to make sure everything is kosher.

        I assume that your connection string does not actually include the html tags for "italic font" -- I think everyone here who is looking at your code is assuming that you put the  <i> ... </i> around "dbname", "uname" and "pword" just for the sake of posting, to clarify that you are (wisely) not showing us the real values that you actually use in those slots to make the connection.

        But just to be sure... if those "i" tags really are there in the script you're trying to run (and/or if that script isn't using the strings provided by the ISP for those slots), then that is surely the problem.

Re: dbh connections: stumped!
by jeanluca (Deacon) on Mar 11, 2006 at 16:41 UTC
    Maybe its better to replace the die for something else. I would suggest
    #!/usr/bin/perl use strict; use DBI; use CGI qw(:standard); use CGI::Carp "fatalsToBrowser"; my $dbh = DBI->connect("dbi:mysql:database=dbname;host=localhost", "uname", "pword") ; print header ; print "<HTML>" ; if ( ! $dbh ) { print "$DBI::errstr: not "; } print "connected" ; print "</HTML>" ; $dbh->disconnect() if $dbh ;


    Luca
Re: dbh connections: stumped!
by thor (Priest) on Mar 11, 2006 at 16:28 UTC
    Nothing shows up in the error log.
    Is this the web server log? That seems odd. I'd suspect that your script having trouble connecting to the database and your script is dying there, but I'm by no means a CGI expert...

    thor

    The only easy day was yesterday

Re: dbh connections: stumped!
by wfsp (Abbot) on Mar 11, 2006 at 16:55 UTC
    Couple of thoughts.

    You could try adding warningsToBrowser (any warnings show up as comments in the source). You could also try printing a message before the connection.

    wfsp