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

I got two for you wizzies:
1. I've written this cgi perl program. It worked great and everything. I made several changes, all of which valid. I've uploaded the program with the new changes, and suddenly it stopped working, giving me (with cgi::carp and fatalstobrowser) this error: Execution of /path-to/downloads.pl aborted due to compilation errors. The debugger gives no errors nor warnings. The script is chmoded 755 and the perl path is correct. I've uploaded the script to 2 of the other servers my site uses and it works there. What might cause such a problem?!
2. I've written another script. This one is kinda simple Photo Album script. It's still under developement. Anyway I haven't used CGI.pm's functions and object's with it so I decided to go through all the script and change it to use CGI.pm's object capabilities. I haven't used CGI.pm's HTML shortcuts cause they really confuse me (The same goes to why I don't use strict). I use CGI::Carp with fatalsToBrowser to catch error message. Perl path is correct, script is chmoded 755, no error messages nor warning using perl debugger. Before changes, the script worked, now I don't even get the CGI::Carp error messages, just that darned 500 error message. If anyone can please check and tell me what might cause this, I will be very gratefull. I've put it on a text file here: http://www.bnei-yehoda.co.il/coranto/picturecg.txt Thanks again guys

Replies are listed 'Best First'.
Re: Too little biggy problems
by The Mad Hatter (Priest) on Aug 01, 2003 at 18:16 UTC
    1. The script can't compile on the server for some reason. Run perl -c /path/to/your-script.pl on the server to see what is wrong.

    2. If you aren't using strict, many monks will refuse to even look at the code and try to figure out what the problem is. It is in your best interests to use strict for every Perl program you write (at least until you understand what is going on, and when it is ok not to use strict). Please read Use strict warnings and diagnostics or die.

    3. (Update) If something confuses you, then that is the perfect excuse to LEARN more about it. Read the docs, ask around, but don't just give up.
Re: Too little biggy problems
by sgifford (Prior) on Aug 01, 2003 at 18:39 UTC
    My favorite trick for debugging CGI scripts when you only have FTP access is to write a short shell-script wrapper like this:
    #!/bin/sh -x
    
    printf "Content-type: text/plain\n\n";
    exec 2>&1
    
    ./downloads.pl
    echo "Exited with status $?"
    
    That will show you whatever errors you would see if you were running your script from the command-line on the server.

    Of course, if you can look in your server's error log, that's simpler and quicker.

Re: Too little biggy problems
by blue_cowdawg (Monsignor) on Aug 01, 2003 at 18:12 UTC

        I made several changes, all of which valid. I've uploaded the program with the new changes, and suddenly it stopped working, giving me (with cgi::carp and fatalstobrowser) this error: Execution of /path-to/downloads.pl aborted due to compilation errors.

    Have you tried running a perl -c check of it? Have you added:

        use warnings; use strict; use diagnostics;
    to your code?

    Please include your code here rather than providing a link to the outside world... thanks.


    Peter @ Berghold . Net

    Sieze the cow! Bite the day!

    Test the code? We don't need to test no stinkin' code! All code posted here is as is where is unless otherwise stated.

    Brewer of Belgian style Ales

Re: Too little biggy problems
by ChrisR (Hermit) on Aug 01, 2003 at 18:37 UTC
    I had a problem like that quite some time ago. This may not be the same thing though, just a thought. I was creating and testing my scripts on a windows box (unfortunately). The problem was that I was uploading them to a linux box. The line endings from windows caused compilation errors. After replacing the bogus windows line termination characters, everything worked fine. Again, this may not be the problem at all (since you didn't specify the OS of the development or production machines), it's just a thought.

          I was creating and testing my scripts on a windows box (unfortunately). {snip!} After replacing the bogus windows line termination characters, everything worked fine.

      OMG! I haven't worked on a Windows box to develop code that I forgot all about that happening to me. I was consulting for a company that their development environment and all their version control tools were on Windows NT and the same exact thing happened to me. So I downloaded a X-11 server for Windoze NT and used XDM to log onto a Solaris box that way. Never had that issue again. (They had an analog to their VC software on Solaris)


      Peter @ Berghold . Net

      Sieze the cow! Bite the day!

      Test the code? We don't need to test no stinkin' code! All code posted here is as is where is unless otherwise stated.

      Brewer of Belgian style Ales

      I have a couple of notes about this problem.

      If you use #!/usr/bin/perl -<options> -- The shell and perl will ignore everything after the -- including the return.

      If your ftp (on both ends) is not broken, transferring the files in ASCII mode should fix up the line breaks to be the correct variety on both ends of the link as needed.

      Some windows ftp clients see that the remote end is Unix and so use binary mode for everything which, of course, is not the correct behaviour.

Re: Too little biggy problems
by ido50 (Scribe) on Aug 01, 2003 at 19:05 UTC
    Thanks guys for the comments.
    About my first problem:
    -blue_cowdawg: I can't run perl -c on the script. At least I think I can't. I only have FTP access. I'm not using, strict, warnings or diagnostics.
    -ChrisR: Thanks, but that's not it. I'm working on a unix box as needed.
    -sgifford: What kinda file is that? It's not a perl program, right?
    -The Mad Hatter: Again, I only have FTP access to the server so I can't run perl -c (As much as I know).

    About my second problem, I'm pretty new with Perl and I guess I was just feeling comfortable without use strict. I guess now as I'm moving forward I find the need to really use it, so I guess I will read the use strict article and docs and get back to you with my second problem (If needed).

    Thanks again, and I hope to get more comments about the perl -c thing.
      sgifford's bit of code was a shell script. Just upload it like you would a Perl script (and put it in the same dir as your download.pl).

          I can't run perl -c on the script. At least I think I can't. I only have FTP access. I'm not using, strict, warnings or diagnostics.

      Run the perl -c on your local machine if you are developing on a linux (or unix) box. (Of course, make sure you have the same Perl modules installed on your local box.

      If there was ever a time for you to use warnings, use strict and use diagnostics, this is one of them.


      Peter @ Berghold . Net

      Sieze the cow! Bite the day!

      Test the code? We don't need to test no stinkin' code! All code posted here is as is where is unless otherwise stated.

      Brewer of Belgian style Ales

        The Mad Hatter: Thanks, I'll do that.
        blue_cowdawg: I'm writing on windows, but writing for linux (Well, FreeBSD to be quite honest). I'll try anyway to run perl -c on the script.
        And about the use strict, warnings and diagnostics pragmas, I'll read more about them and do that also.
Re: Too little biggy problems
by Hagbone (Monk) on Aug 01, 2003 at 22:19 UTC
    Just a FWIW ... here's something I've used when trying to get the browser to display error messages in situations where my access to tools is limited. I grabbed this from a list/group years ago, and don't pretend to be able to explain the finer points of what makes it tick....

    #Put the following code at the top of the script, just below #!/usr/bi +n/perl. #Run the program from your browser, and read what is printed there. BEGIN { local($|) = 1; # Temporarily turn off bufferi +ng print "Content-type: text/plain\n\n"; my $date = localtime; print "Script $0\nrunning on $date (Perl version $])\n\n"; unless (open STDERR, ">&STDOUT") { print "Can't redirect STDERR: $!"; exit; } print "\n"; }