Um ... Apache doesn't pass in arguments on the commandline - because that's not what the CGI spec says. I'd suggest reading the CGI module's documentation for a lot of information on this - that's where I learned how to deal with Apache, and it has worked wonderfully.
After reading the CGI module's docs, I'd suggest CGI::Application and HTML::Template as your next steps into CGI programming. They take a lot of the tedium out, and you can get to the fun parts of coding much faster.
| [reply] |
Hmmmm ... so that must mean that the commercially hosted site I tested it on runs a web server other than apache? I guess I just imagined that everyone on x-nux was using Apache. My bad. I guess I'll need to go back to the books. Thanks.
| [reply] |
Most do run Apache, but most do not run mod_perl. This has to do with security issues on shared machines.
As far as cgi not working with Apache, that is probably a settings issue. First, mod_cgi has to be enabled in Apache, and secondly, the directory that your script is in has to be configured within apache (through a .conf file or a .htaccess file) to allow the execution of scripts.
These are not the only potential issues, permissions being another, but these are the ones most people have issues with the most. Is the configuration of your local machine set up to run the perl script as a cgi script? I would be willing to bet that the directory you have your script in is not set up to run cgi.
Something like this in a .htaccess file in the directory you want the script to run as a cgi:
DirectoryIndex index.pl
Options +ExecCGI
AddHandler cgi-script .cgi .pl
and then, in the httpd.conf somewhere, put
ScriptAlias /cgi-bin/ "/path/to/script/directory/"
You can use an index.pl script to log efforts to directly access the cgi-bin directory, create your own error page, or whatever. I use this to monitor for attempted cracks into the system. It has actually worked well in stopping some. Returning their IP address after a few tries on a page that says illegal access attempt logged scares most kiddies off. You can also do without it. The fewer things a stranger has access to, the safer you are.
I would develop the code in as much the same environment as what I was going to place it in, so if the host uses cgi-bin, I would use cgi-bin. This helps down the road by eliminating potential issues with differences in environments, like using mod_perl to develop in, but then using cgi to run in production. Bad combination. I would also try to keep my scripts in a directory that is not in the public_html path. Most hosts I work with allow that and it is much more secure.
Good luck to you.
digiryde | [reply] [d/l] [select] |
How do you call this script when it works? You should be using something like the CGI module, not reading @ARGV. It also sounds like you don't really understand the difference between CGI and mod_perl. You do not need mod_perl to run perl scripts under CGI. | [reply] |
When it works, I call it with:
www.commercialserver.com/cgi-bin/fileview.pl?2
When it doesn't work, I call it with:
www.myserver.com/perl/fileview.pl?2
You are correct that I'm not terribly clear about the ramifications of mod_perl, but since it seemed that my Apache was unable to access the standard install of perl, I got desperate and "brought it inside" so to speak with mod_perl. It is ENTIRELY possible that I have a config problem with Apache, but I can't find it if it exists :>(
Thanks ...
| [reply] |
It sounds like you are running it through mod_perl via Apache::Registry. It will not populate STDIN for you the same way that CGI does. You need to either go back to using CGI, which should work fine but you may need a little help, or switch from grabbing the args yourself to using something like the CGI module.
| [reply] |