No, you cant call it that. Or at least if you can then you can also call it "brown pudding". :-)

Dynamic variables exist in a package. So what you mean is that they are members of the package "main".

so there's %ENV, %GET, %POST, %IP, %DEFAULTS, and %DATABASE. This is safer anyway. measure twice, declare once. I'm still not saying i'm right, but anti-soft reference arguments don't float. Maybe it's the hash.

Ok, first off, %ENV is a special variable. Unless fully qualified to be in a seperate package, such as %Foo::ENV it always refers to the %main::ENV aka %::ENV aka %ENV. Next, there is _absolutely_ no reason to set these variables up as dynamic variables if you are creating a single script solution. In fact good practice is that even in the later case you still leave them as lexicals, and provide subroutine accessors for them.

I wonder if a reminder of the beauty of 'local' would also help the case here.

No it wouldn't. Most of the readers here, (no offense) understand local and its uses and misuses better than you do. Try getting the basics down a little better before you play with fire.

After reading dominus's arguments against soft references i still remain. One could spend hours telling you how dangerous using perl is when you use the shebang line.

You completely missed the point of Dominus's writing didnt you? Doing something dangerous when you don't have a choice is ok. Doing something dangerous when you have safer (and more powerful) alternatives is foolish.

Then, i thought of 'local' and did a test... Error 500 in the face.

I perused perldiag and did not find "Error 500" listed. A little further searching revealed that you most likely are reffering to a HTTP error. Ok, you are a beginner CGI programmer, even possibly a script kiddie. Thats ok, in Perlmonks we welcome you, but dont expect us to let bad practice be advised without shooting you down. Stick around, a few months hanging out and youll be a better programmer for it.

This doesn't work.

Well tell it to take its lazy ass off the couch and get a job. :-) Ok humour aside, "doesnt work" is about one of the fastest ways to get people to yell at you. I assume you mean it doesnt do what you want it to do. Which I can only infer from the code...

#!/usr/bin/perl
&tryLocal("name=james&color=red&age=12");
exit;
####################
sub tryLocal{
local $in = $_[0];
@in = split(/\&/,$in);
foreach $li(@in){
($lname,$lvalue)=split(/\=/,$li);
local $$lname = $lvalue;
}
}################# end tryLocal
[download]

#!/usr/bin/perl
use strict;
use warnings;

sub tryLocal{
  my $param_str=shift;
  my @pairs= split(/\&/,$param_str);
  my %params;
  foreach my $pair (@pairs) { 
    my ($key,$value)= =split(/\=/,$pair);
    $params{$key}=$value;
  }
  return %params
}

my %params=tryLocal("name=james&color=red&age=12");
[download]

This works.

Well, insofar as it sort of does what you want it to do, you are correct. But it doesnt run under strict. And what happens if I come along and add some code:

@in=qw(foo bar baz);
tryLocal("name=james&color=red&age=12");
print "$name : @in\n";
[download]

Which leads me to say. I was wrong. As you fall in love with local (which i have been doing all summer), you must abandon my old ways. Create your hash and check $TEMP{$passcode} instead of $passcode.

Im not really sure what all this means. The simplest thing that you can do to improve your programming skills is to turn strict on. That will force you to abandon all of your old ways and replace them with better ones, and eventually learn when the old ways were actually the right way, along with why most of the time why the old ways were the wrong way.

A little tip. This is one of the best places to learn quality perl. Hang out listen and learn, ask questions and such. But dont try to tell us that our hard learned lessons are BS. At least not until you know enough to not use phrases like main root hash environment.

:-)

--- demerphq
don't use symrefs until you understand why you shouldn't use symrefs

2 follow-up question if you're up for it:
1.) i turned on strict and was amazed at
all the crap i was doing wrong!
I also tried to incude the library 'warnings'
which failed (my perl is 5.005), is the
shebang -w switch a suitable substitute
for use warnings lib?


Will
#!/usr/bin/perl -w
work in place of
use warnings;
[download]

2.) Do you see anything fundamentally flawed with my
use of 'my' instead of local? The strict and -w switch
stopped outputing bad news to my error logs, so am i
okay now? Or is there something else i don't know about
to keep me on the right path to using perl correctly.


#!/usr/bin/perl -w
# this script outputs a gif 
# set color, width, and height
use strict;

&printGIF("FF0000","33","10");
######################################
sub printGIF{
my $color = $_[0];
my $WH = sprintf("%lX",$_[1]);
my $HH = sprintf("%lX",$_[2]);
$color =~ s/(..)(..)(..)/$1\|$2\|$3/;
my($RH,$GH,$BH)=split(/\|/,$color);
print STDOUT "Content-type:image/gif\n\n";
my @gif=(
"47", "49", "46", "38", "37", "61", "$WH", "00", 
"$HH", "00", "A1", "01", "00", "$RH", "$GH", "$BH",
"FF", "FF", "FF", "00", "00", "00", "00", "00", 
"00", "21", "F9", "04", "05", "00", "00", "01", 
"00", "2C", "00", "00", "00", "00", "$WH", "00", 
"$HH", "00", "40", "02", "$HH", "84", "8F", "A9", 
"CB", "ED", "0F", "A3", "9C", "B4", "DA", "8B", 
"B3", "DE", "9C", "17", "00", "3B"
);
binmode (STDOUT); # if needed
foreach my $bit(@gif){
my $bita = hex($bit);
$bita = pack("C",$bita);
print STDOUT $bita;
}
}#################################### end printGIF
[download]

When i say correct use of perl i mean a clean running
program which could open and close millions of times
with no overflow problems.
jtrue

One could spend hours telling you how dangerous using perl is when you use the shebang line.

Yes, all the Perl vets will spend hours telling you why not to use softrefs. Of course, you're more clever than them.

And CGI is for whimps too, isn't it? You're more clever than Lincoln Stein, and Ovid who spent hours explaining why handrolled CGI parameter parsers are dangerous doesn't have a clue either.

I downvoted your note and was shocked to see people had upvoted you.

Makeshifts last the longest.

The line

my $in = $_[0];
[download]

has nothing to do with the original test i did.
the local test came in with the line "local $lname" vs $lname.
Just had a nice read on 'my'
pretty cool but 'local' works to.
see original question: 205160
I also just read local is better than 'my' for file handles
perlman:perlsub


NOTE: In general, you should be using ``my'' instead of ``local'', bec
+ause it's faster and safer. Exceptions to this include the global pun
+ctuation variables, filehandles and formats, and direct manipulation 
+of the Perl symbol table itself. Format variables often use ``local''
+ though, as do other variables whose current value must be visible to
+ called subroutines.
[download]