Unexpected CGI param behavior

Well, unexpected to me...

#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper 'Dumper';
use CGI;

my $q = CGI->new();

my $var = { first  => $q->param('first'),
            second => $q->param('second'),
          };

print Dumper($var);
[download]

What do you expect $var to be? I expected

$VAR1 = {
          'first'  => undef,
          'second' => undef,
        };
[download]

What I got was:

$VAR1 = {
          'first' => 'second'
        };
[download]

To me, this is unexpected behavior. This is the line that gives us this:

    return unless defined($name) && $self->{$name};
[download]

Changing it to:

    return undef unless defined($name) && $self->{$name};
[download]

gives me the behavior I expect. But, is there a reason why the line as it stands is more correct than my interpretation? Am I the only person who thinks that the current implementation feels wrong?

Comment on Unexpected CGI param behavior Select or Download Code
Re: Unexpected CGI param behavior by runrig (Abbot) on Jun 24, 2008 at 00:42 UTC
If there is more than one param with the same name in the query string, param() return a list of the values (which is documented behaviour)...and that would also mess up your hash array.	[reply]
Re: Unexpected CGI param behavior by pc88mxer (Vicar) on Jun 24, 2008 at 00:47 UTC
I think `CGI` implements this behavior so that `param()` can support both scalar and list context. In list context it returns all the values for a parameter and in scalar context it just returns the first value. If it returned `undef` for unknown parameters, then this wouldn't work: `my @vals = $q->param('...'); print Dumper(\@vals); # would print [ undef ] not [ ]` [download] That is, `@vals` would not be the empty list but a list containing `undef`. A work-around is to use `scalar`: `my $var = { first => scalar $q->param('first'), second => scalar $q->param('second'), };` [download]	[reply] [d/l] [select]
Re: Unexpected CGI param behavior by NetWallah (Monsignor) on Jun 24, 2008 at 00:54 UTC
The fine manual says: If the parameter does not exist at all, then param() will return undef in a scalar context, and the empty list in a list context. (Emphasis mine) Essentially using the reasoning mentioned by pc88mxer. So this is a case of FAD (Functions as documented). ++ for identifying and documenting the issue clearly. "A fanatic is one who redoubles his effort when he has forgotten his aim."—George Santayana	[reply]
Re: Unexpected CGI param behavior by ysth (Canon) on Jun 24, 2008 at 03:19 UTC
For the reasons given by others, the implementation is correct. If you want, you could use: `my $vars = CGI->Vars;` [download] (and then, if you want selected parameters, use $vars->{'first'}, etc.) which has a different icky way of dealing with multi-valued parameters. The correct param() invocation would be: `{ first => scalar $q->param('first'), second => scalar $q->param('second'), }` [download] -- Online Fortune Cookie Search	[reply] [d/l] [select]
Re^2: Unexpected CGI param behavior by Anonymous Monk on Jun 24, 2008 at 09:28 UTC
See (Ovid) Re: Best way to parse CGI params	[reply]
Re: Unexpected CGI param behavior by cLive ;-) (Parson) on Jun 24, 2008 at 20:35 UTC
Hmmm. I guess my beef is with the fact that param() is another victim of "wantarray madness". Ah well, live, learn and write explicit code to solve the issue...	[reply]
Re^2: Unexpected CGI param behavior by ikegami (Pope) on Jun 24, 2008 at 20:39 UTC
You have it backwards, as far as I'm concerned. Your snippet would still fail without `wantarray`. Without `wantarray`, `my $scalar = $cgi->param('foo');` would also fail. That's the case for every function that returns a list. Perl can't return a list in scalar context, so `param` must necessarily return something different in scalar context. `wantarray` simply helps return a meaningful value instead of junk. Since `param` returns a list, feel free to always call `param` in list context if you want to avoid the issue. `my @values = $cgi->param('foo'); my ($first_value) = $cgi->param('foo'); my $first_value = ( $cgi->param('foo') )[0];` [download]	[reply] [d/l] [select]
Re^3: Unexpected CGI param behavior by cLive ;-) (Parson) on Jun 25, 2008 at 06:25 UTC
"would also fail" - um, no it wouldn't, because it explicitly returns a scalar undef. I've tested it. Of course, what it would do is change an array assignment: `# from @array=(); # to: @array=(undef);` [download] Which would be an unacceptable change to existing behavior (exists $array[0] value would change from empty string to 1).	[reply] [d/l]
Re^4: Unexpected CGI param behavior by ikegami (Pope) on Jun 25, 2008 at 07:37 UTC


Do you know where your variables are?
	PerlMonks

Unexpected CGI param behavior

How many continents have you visited?