in reply to Re: Re: Re: Many strings make one variable?
in thread Many strings make one variable?

I let these dynamic variables as listed above exist in the main root hash environment (if you could call it that).

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]
Ok, well why doesnt it do what you want it to do? Well first turn on strict and warnings. Then rewrite it so that it compiles under them. Then apply some rudimentary programming skills to resolve it. 
#!/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]
But of course if you really need to parse parameter strings then you should look at CGI or a similar module. Parsing parameter strings is not as strightforward as this code suggests.

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]
Oops. So now you need to localize everything... But why bother, why not declare all of these variables as lexicals and pass them around _explicitly_ instead of _implicitly_ with all the dangers it carries?

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

Replies are listed 'Best First'.
Strict, my and warnings
by true (Pilgrim) on Oct 15, 2002 at 21:53 UTC
    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
[reply]
[d/l]
[select]

      Yes, the -w switch is acceptable - there was in fact no warnings pragma before Perl 5.6, so it's a fairly recent thing. I still prefer -w for the time being as I never need to switch off warnings anywhere, anyway. (The warnings pragma allows for a more finegrained control if you do: you don't have to switch warnings off entirely anymore, you can selectively disable only specific ones.)

      The script is fine, "clean" wise, but could be written quite a lot more succintly. The only technical mistake is writing "$WH" etc where $WH (without the quotes) would do. If you're only using a single variable, you almost never want to put it in quotes. (There are a rare few cases, but you'll know those when you see them.)

      One thing I strongly urge you to, though, is to properly indent your code. It is barely acceptable in that short script, but would make a more complex one completely unreadable.

      Another note is that you're outputting a CGI header in your printGIF routine: if you go to the trouble of writing a function, then make it do exactly one thing. In this case, generate a GIF file. Nothing else. The header, in this case, is the main program's job. That way, you get functions you can reuse in other scripts later. For the same reason I would have the function return the GIF file, rather than printing it to STDOUT directly.

      Which brings up another point you might want to know about: the $|++; I dumped in there. See Suffering from Buffering about it.

      Here's how I'd write that:

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

$|++;

binmode STDOUT;

print "Content-Type: image/gif\n\n";
print gif_file "FF0000", 0x33, 0x10;

######################################
sub gif_file{
    my ($hexrgb, $wid, $hgh) = @_;

    my %c;
    @c{qw(r g b)} = map hex, unpack "A2"x3, $hexrgb;

    return pack "C*", (
        0x47, 0x49, 0x46, 0x38, 0x37,  0x61,  $wid,  0x00,
        $hgh, 0x00, 0xA1, 0x01, 0x00, $c{r}, $c{g}, $c{b},
        0xFF, 0xFF, 0xFF, 0x00, 0x00,  0x00,  0x00,  0x00,
        0x00, 0x21, 0xF9, 0x04, 0x05,  0x00,  0x00,  0x01,
        0x00, 0x2C, 0x00, 0x00, 0x00,  0x00,  $wid,  0x00,
        $hgh, 0x00, 0x40, 0x02, $hgh,  0x84,  0x8F,  0xA9,
        0xCB, 0xED, 0x0F, 0xA3, 0x9C,  0xB4,  0xDA,  0x8B,
        0xB3, 0xDE, 0x9C, 0x17, 0x00,  0x3B,
    );
}

      [download]
      I would normally have used $width and $height instead of the shorter forms, but wanted to keep the hexdump aligned and somewhat compact.

      Makeshifts last the longest.

[reply]
[d/l]
        I never need to switch off warnings anywhere,

        Interesting. There a bunch of modules that I routinely use that produce warnings under -w. In fact I spent a day trying to figure out what I was doing wrong, only to realize that my colleague had slipped a -w into the script and that nothing was wrong. (Win32::Eventlog is the latter mentioned module)

        Personally I think that the late introduction the warnings modules and its consequent slow takeup and usage was one of the few serious language errors that was made in the earlier versions of perl. (Strong words I know, but im entitled to an opinion :-)

        I suspect that perl6 will have a quite powerful warning and strictures structure from the get-go as a lesson learned from this.

        --- demerphq
        my friends call me, usually because I'm late....

[reply]
        Didn't see anything in the
        link about $|++
        Do you mean $|=1

[reply]
      Will -w work in place of use warnings;

      Yes. But use warnings is more powerful and localized to the module it is used in. If/when you upgrade to 5.6 or later then try to get into the habit of using warnings and not -w.

      As for the code, it looks ok to me. (In principle.) Although I might write 

      my $bita=pack("C,hex($bit));

      [download]
      instead. And 
      my($RH,$GH,$BH)=($color =~ /(..)(..)(..)/);

      [download]
      Also it would be a good idea to get into the habit of indenting properly. You can check out the tool "PerlTidy" hosted on source forge to do have it done automatically for you. perlstyle will have some hints for you with regard to programming style. For instance $RH is not the best var name. To me it implies a filehandle or something else with "mystic" overtones (due to its captialization). I would probably have just used $red instead...

      Ultimately it looks like you are on the right path... Keep it up!

      HTH

      --- demerphq
      my friends call me, usually because I'm late....

[reply]
[d/l]
[select]
        Funny(Horrid) thing to share regarding the lack of -w and strict...
        I've been running a dozen linked perl scripts for
        several websites for 2 years now.
        Very sloppy, but working code with
        global dynamic variables, lack of 'my',
        and a few 'locals' where they should not be.
        I turned -w on...
        my apache error log generated 14,267 warnings.
        This is the total number of warnings issued for
        1 single request to one cgi.

        The main cgi only had 5041 lines of code,
        93 subroutines,
        and 2 to 3 requires.

        jtrue

        P.S. running strict was an impossibility.
        Apache said "unsafe" at line four and sacked the cgi.
        Guess what i'll be doing for the next couple of days.

        (See i don't mind showing my butt cheeks).
        In two weeks i'll be stronger.

        thanks for your help demerphq
[reply]

In Section Seekers of Perl Wisdom