Ive also been looking at how to make my scripts more secure.

My perl for dummies doesnt meantion these.....
and the other book I have is far too cumbersome to look through!

Ive also been looking at how to make my scripts more secure.
They run in a seperate .htaccess protected cgi-bin folder,
i finally implimented use strict, warnings and perl-w on *MOST* of my scripts,

but one script that deals with paypal doesnt like use strict if I do it.

ive predeclared all my local variables in the first two lines of code as such:

my ($first, $second etc....);

is this an acceptable way to do it?

Im of the oldschool Basic pre 1985 model and am used to using any variable i pull out of the ether so i have about 30 different ones normally per script!

Theres one variable for a 2 dimensional array (%) that I cant declare this way it doesnt like it.... how should I declare something like %thisdata as local?

my %thisdata;

Throw Dummies away.....?! I couldnt exist without the plain english version of events. But I also use Core Perl as reference as well.

But I have another question relating to bulk checking of incoming variables.

The form I have on a webpage has about 10-15 different fields, some of which are arrays (@c = param 'c1' for example).

In order to substitute out all the special chars with blank spaces for all of them would require a long list of s/// es!

I thought about putting the incoming variables into an array something like @array = ('$c1', '$email_address', '$other_incomer'); and checking through them all in a foreach statement. Thats ok but obviously then I need to transpose the original values back to the appropriate $ tags.

Has anyone got a better solution. At this rate I may as well plod on with individual checking on each input.

my $p1 = param('param1'); 
my $p2 = param('param2'); 
my @pa = param('multi_valued_param'); 
my $p3 = param('param2'); 
 
foreach ($p1, $p2, @pa, $p3) { 
  s/\W/ /g; # or whatever cleanup you want to do 
}

2/ When asking a question, the best approach is to supply a short, but complete program that we can run, together with an explanation of the output that you expect to see.

3/ Perl has two completely different sets of logical comparison operators. ==, !=, >, >=, <, <= and <=> all treat the two operands as numbers. eq, ne, gt, ge, lt, le and cmp all treat the two operands as strings. See perldoc perlop (the sections on relational operators and equality operators) for more details.

I assume this is another area where the author of "Perl for Dummies" doesn't really know what he's talking about and therefore writes a confusing explanation :-)

In Reply To

Thats almost impossible to forfil. The script is too large to condense

$first = 11; 
$second = 3; 
 
if ($first == $second) { 
  print "equal\n"; 
} else { 
  print "not equal\n"; 
}

and in my experience, anyone who pastes more than ten lines of code gets ignored anyway!

In Reply To

You know, for a book that actually led me to this site (its listed in ten good resources near the end), you are very harsh on the author. If anything, it showed me this place to get more information,

Please dont assume anything is bad simply because someone writes a bad review or all the bits of the book dont match your ideas of what it should be. For Dummies like me, using it purely for referencing back to terminology its ok. Its not great I agree, but it has helped me in the past. And I do reference to Cpan, perldoc and other sites. I have taken your suggestion to change and I have now put it in the cupboard and rely on my copy of core. Im changing the error of my ways! Re:Bad Author, my limited knowledge of BASIC programming stood me in good stead with Dummies. So when the author runs off into big scripts and doesnt explain them the way others think he should, I can usually decypher and understand them. What works for one person, doesnt necessarily work for the others. And of course, I thankfully have this place to search through!