StevenMiles
asked on
Why do I get Odd number of elements in hash error and garbled input in POST to perl script
Hi,
I'm working on a perl program that will take input from various text box form fields and do some processing. I was parsing the POST information myself, but was advised, on this site and in other reading, to use CGI.pm to do it. In fact, I ran into a problem that if the user put "%" or "&" in a text box, it would garble the input, a problem that CGI.pm corrected.
However, now I've been seeing a new problem that I can't debug. Here is how I am now obtaining the info from the text boxes and putting it into the hash that I use throughout the rest of the program:
use CGI;
my $query = CGI->new();
my @names = $query->param;
foreach my $name ( @names ) {
$value = $query->param( $name );
$args{$name} = $value;
}
Sometimes, inconsistently, I'll get the following error:
Odd number of elements in hash assignment at /home/www/MySite/root/cgi-
Then, I have some debugging code that says:
foreach $key (keys (%args))
{print STDERR "$key = $args{$key}\n"}
And instead of printing out the expected:
txtEmailAddress = bill@here.com
txtFirstName = Bill
txtLastName = Smith
etc.
... it prints:
txtEmailAddress=bill@here.
See the lone equals sign on the right? It looks like there was only one "key" and no "value", thus an odd number of elements.
This wouldn't be in part because sometimes a text box is left blank by the user, would it? I have to assume that a user would leave a box blank sometimes.
I say the problem was inconsistent, in that sometimes it wouldn't happen, and the input would parse correctly, with everything else being the same, even restarting the server just before each test.
I'm using linux/Apache2/mod_perl.
After doing more reading on CGI.pm, I changed the code that processes the input, to:
use CGI;
my $query = CGI->new();
%args = $query->Vars;
which also seems to work fine, but I don't know if sometime in the future it will show up with the "odd number of elements" error, too.
I *need* the POSTs to process accurately every time. Can anyone recognize something I'm doing wrong, or know of something different that I should be doing that would be safer and more effective? I'd appreciate any help.
Thanks,
--Steve D.
Update: I'm having trouble re-creating the "odd number of elements" error. Making me crazy here. I hate problems that I can't consistently recreate.
/SD
I'm working on a perl program that will take input from various text box form fields and do some processing. I was parsing the POST information myself, but was advised, on this site and in other reading, to use CGI.pm to do it. In fact, I ran into a problem that if the user put "%" or "&" in a text box, it would garble the input, a problem that CGI.pm corrected.
However, now I've been seeing a new problem that I can't debug. Here is how I am now obtaining the info from the text boxes and putting it into the hash that I use throughout the rest of the program:
use CGI;
my $query = CGI->new();
my @names = $query->param;
foreach my $name ( @names ) {
$value = $query->param( $name );
$args{$name} = $value;
}
Sometimes, inconsistently, I'll get the following error:
Odd number of elements in hash assignment at /home/www/MySite/root/cgi-
Then, I have some debugging code that says:
foreach $key (keys (%args))
{print STDERR "$key = $args{$key}\n"}
And instead of printing out the expected:
txtEmailAddress = bill@here.com
txtFirstName = Bill
txtLastName = Smith
etc.
... it prints:
txtEmailAddress=bill@here.
See the lone equals sign on the right? It looks like there was only one "key" and no "value", thus an odd number of elements.
This wouldn't be in part because sometimes a text box is left blank by the user, would it? I have to assume that a user would leave a box blank sometimes.
I say the problem was inconsistent, in that sometimes it wouldn't happen, and the input would parse correctly, with everything else being the same, even restarting the server just before each test.
I'm using linux/Apache2/mod_perl.
After doing more reading on CGI.pm, I changed the code that processes the input, to:
use CGI;
my $query = CGI->new();
%args = $query->Vars;
which also seems to work fine, but I don't know if sometime in the future it will show up with the "odd number of elements" error, too.
I *need* the POSTs to process accurately every time. Can anyone recognize something I'm doing wrong, or know of something different that I should be doing that would be safer and more effective? I'd appreciate any help.
Thanks,
--Steve D.
Update: I'm having trouble re-creating the "odd number of elements" error. Making me crazy here. I hate problems that I can't consistently recreate.
/SD
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi, ozo,
I guess I wasn't completely clear. After the CGI code at the top of my post tried to assign the form fields to %arg, the "odd numbered" error occurred when I tried to call a subroutine, passing %arg to the sub. The error happened in the subroutine, on the line: "my %DataForThisSub = @_;"
But the "foreach $key" debug code, which showed that the fields were parsed incorrectly, was immediately after the CGI code to parse the input and create %args. The question is still why the parsing didn't work, and whether there is a safer way to parse the POST input that would avoid whatever error is happening here.
/S
I guess I wasn't completely clear. After the CGI code at the top of my post tried to assign the form fields to %arg, the "odd numbered" error occurred when I tried to call a subroutine, passing %arg to the sub. The error happened in the subroutine, on the line: "my %DataForThisSub = @_;"
But the "foreach $key" debug code, which showed that the fields were parsed incorrectly, was immediately after the CGI code to parse the input and create %args. The question is still why the parsing didn't work, and whether there is a safer way to parse the POST input that would avoid whatever error is happening here.
/S
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
/home/www/MySite/root/cgi-