You're somewhat right -- CGI forms can get input from STDIN, but they only get the content that's been sent to them. (you'd normally get this data from a form submission with method='POST') There is also data that's passed in through $ENV{'QUERY_STRING'}, which you'd get if you used a form with method='GET', or if you encoded it manually into a URL, such as:
http://server/path/script?param1=value1a;param1=value1b;param2=value2For older CGI scripts, you'll have to use amperands instead of semicolons to seperate the key/value pairs, but you then have to encode them in the HTML, like so:
http://server/path/script?param1=value1a&param1=value1b&param2=value2To make things even more confusing, you can also pass things in through $ENV{'PATH_INFO'}, by giving a URL with path information past the script, like so
http://server/path/script/arg1/arg2/arg3(You don't have to seperate the arguments with slashes -- I don't think there's a set convention for that one)
But, it gets worse when you consider that you could declare a form with
<form action='http://server/path/script/PATH_INFO?QUERY_STRING' method='POST'>which would result in three different sources of input. And let's not forget that you could also pass extra input in the HTTP headers.
So, what's the solution to all this? Well, use CGI or use CGI::Lite would probably be the easiest, and let them do all the work:
use CGI::Lite; my $cgi = new CGI::Lite; my %input = $cgi->parse_form_data();
Update : missing a 'my'. Doh.
In reply to CGI input
by jhourcle
in thread My cgi nonsense.
by tgolf4fun
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |