http://qs321.pair.com?node_id=188605

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

I have a number of separate CGI's that I have decided to package together to accomplish a number of related tasks. Each CGI is a stand alone program, and each had a configuration section.

To simplify things, I decided to take all the configurations sections of each CGI and lump them together into a config.pm file, then call that file from each CGI with a "require" statement:

require "config.pm";

Simple, or so I thought. I continually get a "500 Server Error". I made sure that the config.pm had a ending "1;" line to return a true; I replaced the "require" statement with the original config lines and the CGI's work fine, but the require statement will always return a server error.

I've also tried:

1. use "config.pm";
2. BEGIN {require "config.pm";}

Are there certain restrictions on using the require statement? I have searched through the site on "require use statements" but have not found any "perls of wisdom". Any ideas? P.S. permissions are all set to 755.

Edited: ~Thu Aug 8 15:49:15 2002 (GMT) by footpad: Edited title (for later searching), per Consideration.

Replies are listed 'Best First'.
Re: Sharing Configuration between Multiple CGI Scripts
by waswas-fng (Curate) on Aug 08, 2002 at 15:26 UTC
    I like to use the storable module for this, just do a:

    use Storable; nstore \%table, 'configfile'; $hashref = retrieve('configfile');

    seems to load very fast and works for most of my needs.

    -Waswas
    Edited to s/store/nstore/ as nstore creates a more portable format (config file across multiple platforms etc..)
Re: Sharing Configuration between Multiple CGI Scripts (was: How difficult can)
by fruiture (Curate) on Aug 08, 2002 at 16:14 UTC

    Well, you get a "500 Server Error" from your httpd, but perl certainly gives you a more helpfull message, which can be found in the error-log of your server. I can imagine that you have a nasty ISP that does not give your error-log access: use the module CGI::Carp and import 'fatalsToBrowser', that will catch all occuring errors and spit them to your browser.

    Also note that the current working directory is not guaranteed to be the directory your script is in (although afaik the Apache ensures it), at least no CGI spec says so. Try adding the following BEGIN-Block:

    BEGIN { use CGI::Carp 'fatalsToBrowser'; require FindBin; chdir $FindBin::Bin; }
    --
    http://fruiture.de
Re: Sharing Configuration between Multiple CGI Scripts (was: How difficult can)
by Abigail-II (Bishop) on Aug 08, 2002 at 16:10 UTC
    Well, we could all guess a reason, but that's not going to be very efficient.

    Perl will tell you what is wrong. Look in the server log file, or simulate a web server and look what perl has to say about it.

    Abigail

Re: Sharing Configuration between Multiple CGI Scripts (was: How difficult can)
by belize (Deacon) on Aug 08, 2002 at 16:29 UTC
    The result of using CGI::Carp was that the config.pm file did not return a true value even though I had a:

    1;

    line at the end. I then changed the line to:

    return 1;

    and all worked fine. Is this a requirement of Perl 5.006? or should one always use:

    return 1;

    Thanks for the CGI::Carp suggestion, we did not have access to the error logs.

      Yes, you need always to return 1 from modules. Please read man perlmod, particularly the section about Perl Modules.

      Ciao, Valerio

      You should not need to say "return 1;". Just putting a "1;" at the end of the file should be enough. Maybe you have something after the "1;", like some POD? If you put POD at the end, you would typically put the "__END__" marker before it.
        Nope, I had only 1; at the end and it won't work, though I might have had a line return.
Re: Sharing Configuration between Multiple CGI Scripts (was: How difficult can)
by dws (Chancellor) on Aug 08, 2002 at 16:36 UTC
    I continually get a "500 Server Error".

    Debugging 101 suggests that you first verify that your script runs from the command line. Does it?

      Found the problem, see answer above yours.

      By the way, we don't current have access via the command line with our current server. Should probably set up an in-house server for testing.