It also makes it easier for the potential intruder to wreak havoc with your script.

Never ever use user input to determine a variable name!

Consider what happens when a malicious abuser of your script submits a field name of, for example, mailhost, dbname or maybe simply adminmail - this method would directly overwrite the variable of that name, and it's just a matter of determination until the abuser finds out a combination that works for their purposes.

For the bare minimum, you should check that each parameter is in your scripts list of known good parameters, and you most definitively must use taint mode (#!/usr/bin/perl -wT as the first line of the CGI script) to alert you of more pitfalls when handling insecure data.

My approach would be to either use CGIs feature of importing the parameters into their own namespace or simply use the param() function where appropriate. Wildcarding the field names will give you much pain in the future.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

Your solution might be fast, but it also allows anyone to clobber the value of any variable in the package's namespace. Depending on how you code, this may or may not be a problem, but me thinks it's better to avoid the problem entirely.

Instead, explicitly put all the names of the fields you allow in an array. My arg-parsing routines usually look something like this:

{
    my @FIELDS = qw( foo bar baz );
    sub set_params 
    {
        use CGI qw(:standard);
        map { $_ => param($_) || '' } @FIELDS;
    }
}

# Other subroutines here 

{
    my %params = set_params();
    # Call other subroutines here 
}
[download]

It's much safer, and a change in the fields only means a change in the @FIELDS array. I use a similar form for object constructors:

{
    my @FIELDS = qw( foo bar baz );
    sub new 
    {
        my $class = shift;
        my $in    = shift || { };  # Passed in a hashref
        my %self  = map { $_ => $in->{$_} || '' } @FIELDS;
        bless \%self, $class;
    }
}
[download]

my %pairs = $cgi->Vars();
[download]

my $name = $pairs{name};
now $name will contain 'bob'
[download]

This method also elegantly handles input fields with multiple values, such as checkboxes and pulldown menus (multiple select). If the name parameter that bear0053 describes is from a set of checkboxes, and the names Bob and Joe were selected, $pairs{name} would contain 'Bob' and 'Joe' separated by NULL character ( \0 ). Very easy to parse, if needed. I think that your way will squash all but the first value (not very nice if you're Joe).

You will need CGI version 2.53 or higher to use Vars().

bassplayer

any pitfalls or better ways of doing this?

Yes, two of them. First, this code won't run under strict, and second, it allows malformed input to set any global variable it wants, which could do unforseen things with your script. You can solve both of these problems in either of two ways. The first is to use a single hash, instead of many globals. This is what I do:

foreach my $field ( @params ) {                    
    $input{$field} = param( $field );    
}
[download]

This requires the rest of your script to use the hash values (like $input{foo} instead of just $foo), but it's straightforward and works. The other way is to expressly list what variables the user is permitted to set, and ignore any others. In order to get it to run under strict, you also have to add a line to allow the symbolic references:

foreach my $field qw(foo bar baz quux wibble) {        
    no strict refs;
    $$field = param( $field );    
}
[download]

This still requires you to list all the variables, but you don't have to have a separate assignment line for each, and you don't have to change the rest of the script to use a hash.

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

Yes. You're now at the whim of whoever forges a form.

Leave it the way it was. You gain little by your change, except saving yourself a bit of typing, and you lose control over your namespace.

Be explicit with what you expect in the form, and you'll make it easier on yourself when you pick the code up 6 months from now to make a change.

use CGI::Lite;
my $cgi = new CGI::Lite;
[download]

$form = $cgi->parse_form_data;
%form = $cgi->parse_form_data;
$form = $cgi->parse_form_data ('GET', 'HEAD' or 'POST');
[download]

print "blabla bla bla $form->{entry} blabla<br>\n";
[download]

In 25 words or less, what exactly is "namespace?" From what I can tell, it is the area inside my script where I assign the variable names and what is in them. Anyone care to expound?

In 25 words or less, what exactly is "namespace?"

Check out the perlfunc entry for package.

Hmm... that's 7 words. I'll just give you a final example:

#!/usr/bin,/perl -w
$x = "MAIN";  # in default package, "main"
package Foo;
$x = 123;     # in package "Foo", so this is $Foo::x
package Bar;
$x = 456;     # in package "Bar", so this is $Bar::x

package main;  # back to normal
print "\$$x = '$x'\n";
print "\$main::$x = '$main::x'\n";
print "\$Foo::$x = '$Foo::x'\n";
print "\$Bar::$x = '$Bar::x'\n";
[download]

This prints:

$MAIN = 'MAIN'
$main::MAIN = 'MAIN'
$Foo::MAIN = '123'
$Bar::MAIN = '456'

In summary: it's a way to have global variables of the same name which nevertheless don't trample on each other. That way you don't have to worry if you happen to use the same name for a variable as used in some obscure module.

Commonly modules have their own package, and the standard convention is that it's the same as the module name. use relies entirely on that convention for it's import mechanism — which is a way to make variables and subs visible unqualified across package boundaries, by making aliases to the same variables in the different packages. Thus, if you import $Foo::x into Bar, then $Bar::x will point to the same variable as $Foo::x does. Any modification of one will be reflected in a change in the other.

You're probably familiar with that effect, but you likely didn't realise how simple the underlying implementation really is. Because it is.