in reply to browser not executing perl

You need a webserver, as Beatnik already noted. Apache can be daunting to set up at first (update: or maybe the package emcs++ mentions makes it not so), so you might want to start out with Ritlab's TinyWeb server. If you do, I would advise you to upgrade to Apache sometime anyway, because TinyWeb's CGI support is rather limited in some ways. But it's enough to make first steps with, and it's quick to set up so you can go about learning Perl for the time being and forget about the more intricate details of running a webserver.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re: browser not executing perl
by jepri (Parson) on Jun 19, 2002 at 23:50 UTC
    Or just roll your own webserver with HTTP::Daemon. It's suprisingly easy for a one-shot script. Multiple functions cause minor headaches.

    Update: I dispute that Apache is hard to setup on Linux. Many distributions will install it unless restrained at install time. To use scripts with it, you copy your script into your cgi-bin directory, name it script.cgi, chmod a=rx script.cgi and you are off and running. Even microsoft couldn't make it any easier.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.

[reply]

      While HTTP::Daemon may be easy to use, it is not advisable practice. For one, if you need to write a script to run on YourAverageHost.Com, it will invariably be a CGI script. Even when that is untrue and the script in question is going to run on your own machine, running a HTTP daemon for every single script you may or may not need at one time or other is simply an unnecessary waste of resources (memory, CPU, socket handles) and presents a box with a million open ports to anyone who happens to scan you. And without meaning to be condescending to her, if danielle is asking such a question I doubt she has the experience to have a grasp of all of the security concerns that play a role in writing a daemon (although admittedly CGI is only marginally friendlier an environment).

      In specific scenarios, HTTP::Daemon may be the tool to use. For the common tasks, it's not. Use the right tool for the right job..

      Makeshifts last the longest.

[reply]
        Ooops, sorry, I'm going to swat you on that one. While you might be suprised at the number of HTTP::Daemons you can start before your system slows, there is no problem with open ports. Perl is incredibly secure, and fooling the perl interpreter remotely to do something bad is unheard of.

        danielle would not be writing a daemon, because HTTP::Daemon is the daemon. And HTTP::Daemon is pretty good. The only way you can stuff it up is to send a huge POST request, and then the OS will just swat the daemon for taking up too much room.

        I will totally agree with you that HTTP::Daemon is not the right tool for the job most of the time, though.

        ____________________
        Jeremy
        I didn't believe in evil until I dated it.

[reply]

In Section Seekers of Perl Wisdom