in reply to eval not behaving like I expected... why?

I think you're forgetting that my produces a lexical variable that isn't attached to a package namespace. Since you're creating them inside a string eval, they go out of scope as soon as it ends, leaving you with the same variables you had when you entered that string eval (that is, none).

For a quick strict-compliant fix, change all of your mys to ours—alternatively, use vars qw($fee $fi $fo @fum); and dropping the my entirely would have a similar effect.



If God had meant us to fly, he would *never* have given us the railroads.
    --Michael Flanders

Replies are listed 'Best First'.
Re^2: eval not behaving like I expected... why?
by blue_cowdawg (Monsignor) on Mar 13, 2006 at 21:34 UTC
        I think you're forgetting that my produces a lexical variable that isn't attached to a package namespace.

    That being the case, (and I'm agreeing with you) why does this work?

    use Inline::Files; use Data::Dumper; open CACHE or die $!; # read access (uses $CACHE to locate file) eval join "", <CACHE>; close CACHE or die $!; print "\$var was ’$var’\n"; while (<>) { chomp; $var = $_; print "\$var now ’$var’\n"; } open CACHE, ">$CACHE" or die $!; # write access print CACHE Data::Dumper->Dump([$var],['var']); close CACHE or die $!; __CACHE__ $var = 'old value';
    That's ripped right from the man page for Inline::Filss and it works! Try it!


    Peter L. Berghold -- Unix Professional
    Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg

      The lack of my in the __CACHE__ section has a lot to do with that...