in reply to CGI "control panel" app

You can do just about anything even–

and some sort of event handler, I guess, so that I can start/stop the processes by just changing the checkbox instead of having to "submit" the form.

could be done with Ajax + Perl. But you are talking about a monstrous amount of code (for example, you’d might need to daemonize a bunch of stuff unless for polling you're willing to do slower log/output parsing) with lots of inherent security issues (if it can go bad on the shell, it can be asked to go bad from the CGI) if you’re going to try to control a bunch of stuff.

I agree with dhoss. There are things already out there which are nice and could be tailored if needed.

Replies are listed 'Best First'.
Re^2: CGI "control panel" app
by mojodaddy (Pilgrim) on Jul 24, 2007 at 04:20 UTC
    Yipes! I'm beginning to think I've done a really bad job of asking this question.

    OK, forget everything I said before. What I really want to know is how to do this:

    <form name="myform" action="not_a_cgi.pl" method="get"> <input name="checkme" type="checkbox"/></form>

    in other words, have a form's action execute a regular perl script instead of a CGI.

    Addendum:

    In hindsight, maybe it was referring to my little web page as a "control panel" that led to the confusion. In reality it's a page with an HTML table on it and a refresh button that redraws the table. So maybe "control panel" was overstating it! :)

    And maybe "event handler" was the wrong term (obviously it was if it's something that would require a "monstrous amount" of code), but I just meant something like

    <input name="checkme" type="checkbox" onclick="submitform();">

    I was just too lazy to type it the first time as I wasn't 100% sure on the syntax.

    In any event, thank you for offering your suggestions.

      The only real difference between a CGI script and "not_a_cgi.pl" is that the former prints its results back to the browser along with a content-type header. If you are going to access the script via a regular HTML form submit, you need it to print something back, even if that something is just the same form getting redisplayed. If you use AJAX, you can make it so that the checkbox fires off a call to the script without submitting the form or refreshing the page and therefore the not_a_cgi.pl will work fine since it isn't expected to print a content-type header or anything else to the browser. You could also make a little CGI wrapper that calls the not_a_cgi.pl scripts and redisplays the form on success and displays an error message on failure.
        "If you are going to access the script via a regular HTML form submit, you need it to print something back, even if that something is just the same form getting redisplayed."

        There it was -- the insight I didn't even know I was seeking. Thank you!

      I think what you want to do is this:

      Create a CGI wrapper script around your "not a CGI script" script. Inside the wrapper, invoke the regular script using system(), or back ticks:

      $status = `not_a_cgi.pl`;

      Note that this is normally considered a bad idea (security risk, etc) - BUT, if you're only running on localhost, and no one else has access to your machine, and you have some way to guarantee that only you can see the control panel page (maybe a login page?) etc., etc. then it might be okay for what you want to do.

      BUT - keep in mind that the script will run with the user id of the web server. For example, if you're running Apache it usually runs as user "apache", so any files you need to access from within your script must be readable/writable by "apache".

      If this causes problems, you can modify the apache config file so that CGI scripts in your own CGI bin directory run with your user id instead (again, this is usually considered a bad idea, security risk, etc.) but may be okay for what you want.

      I've done stuff like this before, but always within a company intranet, behind a firewall, for internal tools, used only by myself, etc. I'd never recommend something like this out in the wild.

        "if you're only running on localhost, and no one else has access to your machine"

        Someone could break into the house and swipe my laptop, but if that happens I've got other problems. Plus, they'd have to pick a time when I'm not hunched over it, which is rare! : )

        I think what you've suggested will work nicely for me, assuming I sort out any permissions issues with Apache. Thanks!