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

Hi,

Is it safe to call a cgi script from another cgi script . Someone said to me its not wise to do it?Its better to handle it via a module.

The main problem is , when A.cgi calls B.cgi , errors in B.cgi are just written to server log. A.cgi looks as if things went fine.
What i am doing is getting some information in a html form , send the data to another cgi script using AJAX and that cgi script inturn stores the data into db.

Also , if i want to do it using a module instead of cgi , how to do it. Should I be loading cgi modules within that module and then do it or is there any better way?
  • Comment on cgi page calling another cgi when submitting form but does not returns error only to web server log and not to browser.

Replies are listed 'Best First'.
Re: cgi page calling another cgi when submitting form but does not returns error only to web server log and not to browser.
by marto (Cardinal) on Jul 01, 2014 at 15:33 UTC

    Without knowing what the errors are there's little anyone can do to help. Like going to the doctor but not telling them any of your symptoms. Provide the details needed for others to understand your system/setup. Show the errors you find in the logs.

    "Also , if i want to do it using a module instead of cgi , how to do it. Should I be loading cgi modules within that module and then do it or is there any better way?"

    If I understand you correctly you're currently using CGI. If I were starting anything new (web based) I'd use Dancer, other modern frameworks exist. Dancer has extensive documentation and example code.

    When posting here links are displayed by default, including How do I compose an effective node title? and How do I post a question effectively?. Please read and understand them at least once.

    Update: Since you're using CGI Tutorials->Web Programming->CGI Programming->Ovid's CGI Course is worth reading, since you need help debugging your cgi scrips.

      Thanks for the response. The second cgi script inserts data into db. Lets say i mess the insert query. So the script would ideally break with an error. But the problem is error is thrown to the server error log. But parent cgi script which called this db inserting cgi script is not aware of the error that happened.

        Then you should look at the web server (you don't say which) error logs. For Apache this is error_log. Failing that if you read the link I gave you specifically for learning how to use CGI you'll find out how to dump errors in the browser.

        Still not useful info: post code and error messages, verbatim. Anything else we might do is navel-gazing and WAGs.


        check Ln42!

Re: cgi page calling another cgi when submitting form but does not returns error only to web server log and not to browser.
by jeffa (Bishop) on Jul 01, 2014 at 16:24 UTC

    The idea is to refactor the portions of your code that can be shared by A.cgi and B.cgi. Consider the following:

    my $data = 'pretend this is a complex data structure'; my $is_web_browser = 1; if ($is_web_browser) { print qq(<span color="red">$data</span>\n); } else { print qq(\e[0;31m$data\e[0m\n); }
    For this example, sometimes we want to decorate our data one way for one kind of client and another way for another kind of client. Rather than use one file for producing/publishing the data to be displayed as well as decorating that for a Unix command line AND a CGI "web page" ... why not refactor into one module that any number of formatters can consume?

    file: SomeModule.pm

    package SomeModule; use strict; use warnings; sub get_data { return 'pretend this is a complex data structure'; } 1;

    file: app.cgi

    use strict; use warnings; use SomeModule; my $data = SomeModule::get_data(); print qq(<span color="red">$data</span>\n);

    file: app.pl

    use strict; use warnings; use SomeModule; my $data = SomeModule::get_data(); print qq(\e[0;31m$data\e[0m\n);

    This is a very simple and distilled example, but hopefully you see how different apps can reuse the same modules without actually executing each other as a script.

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    
      Thanks , So if i am passing the form data of cgi ( i.e. the $ENV{QUERY_STRING} to this module ) , in that case I should be splitting it using split function and extract the param from there right ?
Re: cgi page calling another cgi when submitting form but does not returns error only to web server log and not to browser.
by Anonymous Monk on Jul 01, 2014 at 16:06 UTC

    Don't "call" other cgi's from a cgi ... whatever you mean by "call"

    using system or exec to call other cgis is a fudgy idea,

    fudgy , unless you're clever enough to write your cgis to take @ARGs, but then if you did that you wouldn't call them cgis :) and you'd be clever enough to use Capture::Tiny to capture anything your cgi prints on STDERR or STDOUT

    but if you wrote both programs, and the second is really just a part of the first, then yeah, it shouldn't exist, it should be part of your module ... yeah, your real cgi should be

    #!/usr/bin/perl -- ... use MyModule; MyModuule::DoTheCgiDance();

    If you still need the "other" then you can have that one too

    #!/usr/bin/perl -- ... use MyModule; MyModuule::DoTheCgiDanceOTHER();

    :)

      If I have to pass the form data to this perl module , How should I be doing it.

      Should i pass the "param" from cgi to this module and split it using split function ?

Re: cgi page calling another cgi when submitting form but does not returns error only to web server log and not to browser.
by perlfan (Parson) on Jul 02, 2014 at 12:02 UTC
    It's already been said, use a modular code organization. I would not use old style CGI. If you are stuck in a CGI type of environment, so called "modern" Perl web frameworks are a pain in the ass for this kind of constraint.

    If you are transitioning from CGI to modernity, then I would recommend looking at CGI::Application. I still use it and it works well in many situations. However, it is not persistent. This shouldn't matter to you at this point.

    CGI::Application encourages modularity and introduces you to a sane way to manage a request life cycle. Once you cut your teeth there, then you can look at the plethera of frameworks out there.