Your hand-made CGI parameter parsing routine has a bug in it (as do most such routines that I've seen). You assume that your CGI query string will only contain each key once. This may be valid in your particular case, but it's not what the CGI spec says.

If your code gets a query string that looks like this:

key1=val1&key2=val2a&key2=val2b
[download]

The 'val2a' value is overwritten with the value 'val2a' in the %form hash.

Why do people insist on reinventing these routines when Perl comes with a module (CGI.pm) which does this right? Why go to all the effort of re-writing it with a bug?

I realise that it probably works fine in your application because you don't use multi-valued CGI parameters, but the danger is that someone else will read your code and cut and paste it into their program.

Dave,

First of all, let me tell you that I am entirely self-taught. I began to hear about the CGI.pm module only recently! Before that, I tried to learn copying&pastings and then re-writing. This is something that I had seen in another script; and I had been using this since.

The CGI parameters, I believe, are just like variables. A variable name should be unique, so should a CGI parameter. I see no problem in assuming that no parameter name will occur twice. I don't know how CGI.pm module handles this, but it looks like an unnecessary detail.

Perl has a real problem in that there are so many badly written CGI scripts around on the web and most people seem to pick up bad habits from them before finding places like perlmonks where they can get good advice. I'd be geniunely interested in hearing any ideas you have about how we can get to new Perl programmers and teach them good habits before they meet Matt Wright and his friends.

Your assumptions about CGI parameters are wrong. It is perfectly valid to have more than one value for each key. CGI.pm handles this by returning a list of values for multi-valued parameters. the older cgi-lib.pl handles it by returning a string where the values are separated by a \0 character. most hand-rolled solutions (like yours) handle it by trashing all but one of the values.

I apologise if my original post sounded too much like a flame. All I wanted to do was to point out that there are much better ways to do what you're doing and I hope that having been shown them, you will start to use them.

--
<http://www.dave.org.uk>

European Perl Conference - Sept 22/24 2000, ICA, London
<http://www.yapc.org/Europe/>

You apparently haven't yet dealt with multiple-select fields then, where you can end up with state=oregon&state=washington&state=california because someone selected all three states from an input field.

Please don't write CGI handling from scratch. There's a lot to get right, and it really does take something the size of CGI.pm to get all of it right.

-- Randal L. Schwartz, Perl hacker

use Math::Complex;
use CGI qw(param);

for my $i (1..$varno) {
  for my $j (1..$varno) {
    next unless my $val = param("val-$i-$j");
    if (my($re, $im) = $val =~ /(.*)([-+].*)[ij]/) {
      $matrix[$i][$j] = cplx($re, $im);
    } else {
      $matrix[$i][$j] = cplx($val, 0);
    }
  }
}
[download]

-- Randal L. Schwartz, Perl hacker

Thanks for the fix!!

Well, it seems that I could use


$matrix[$][$j] = eval( param("val-$i-$j") );
[download]

But I did not want to use eval();

Normally, $C = 5+4j works fine. So under normal circumstances, you don't need a parser... I browsed through the man page, but I did not find anything like that.

It's always worth pointing out this mistake, especially somewhere like perlmonks where the code is archived and someone will read and copy it months or years later.

You're right that in many cases having multi-valued CGI parameters might not be what is required and therefore the script _should_ overwrite them. If this is the case tho', I'd hope to see a a comment saing something like "I know this looks like a bug, but it's OK because..."

I realise that a) my original post looked a bit too much like a flame (I've apologised to the original poster for this) and b) my post didn't address the problem that the original poster was having, but I think that it's important to point out potential bugs in the code on perlmonks so that people who cut and paste from here are aware of the possible traps.

--
<http://www.dave.org.uk>

European Perl Conference - Sept 22/24 2000, ICA, London
<http://www.yapc.org/Europe/>