Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

setting PERL_PERTURB_KEYS & PERL_HASH_SEED in a perl file

by gravid (Novice)
on Jul 14, 2016 at 15:10 UTC ( #1167787=perlquestion: print w/replies, xml ) Need Help??

gravid has asked for the wisdom of the Perl Monks concerning the following question:

Hi

My hash keys sort acts differently in perl v5.18.4 vs v5.8.9

I found out that I can control that using:

setenv PERL_PERTURB_KEYS 0

setenv PERL_HASH_SEED 0x00

However I want to set those within my script and not in the environment.

I tried:

BEGIN {

$ENV{'PERL_HASH_SEED'} = '0x00';

$ENV{'PERL_PERTURB_KEYS'} = '0';

}

But it doesn't work

Any idea?

Thx

Guy

  • Comment on setting PERL_PERTURB_KEYS & PERL_HASH_SEED in a perl file

Replies are listed 'Best First'.
Re: setting PERL_PERTURB_KEYS & PERL_HASH_SEED in a perl file
by haukex (Archbishop) on Jul 14, 2016 at 15:56 UTC

    Hi gravid,

    As far as I can tell from a glance at the source, Perl only checks those environment variables once on startup (the function Perl_get_hash_seed in util.c sets the variables PL_hash_rand_bits_enabled and PL_hash_rand_bits). It might be possible to change the values at runtime from XS code, but that's not my area of expertise.

    But I think it's important to point out that hash ordering has always been random, even though older Perls used to return hash keys with some consistency to the ordering, leading to code sometimes relying on this fact. But at least since v5.18.0 that has changed, see Hash overhaul. The bottom line is, one shouldn't rely on the order hash keys are returned in, in any version of Perl.

    I find the easiest solution is usually something like for my $key (sort keys %hash) ..., or in some cases modules like Tie::IxHash can help. See also How do I sort a hash (optionally by value instead of key)? This might be the "better way" to fix your code than to rely on Perl's hash ordering.

    Hope this helps,
    -- Hauke D

      But I think it's important to point out that hash ordering has always been random, even though older Perls used to return hash keys with some consistency to the ordering, leading to code sometimes relying on this fact. But at least since v5.18.0 that has changed, see Hash overhaul. The bottom line is, one shouldn't rely on the order hash keys are returned in, in any version of Perl.
      Actually it's much older than that. In order to protect perl from some form of DOS attacks, a randomization of key ordering was implemented in perls as old as 5.8.1, so that the next time you run it, you'd most likely get a different keys order for the same hash keys inserted in the same order.

      The reason for that is a possible DOS attack over hash collisions (from 2003) which was fixed that same year in October.

        Hi bart,

        Thanks very much for that, I dimly remembered there had been a change in the past (hence the "at least"), I just didn't think to check perl581delta ;-)

        Regards,
        -- Hauke D

Re: setting PERL_PERTURB_KEYS & PERL_HASH_SEED in a perl file
by FreeBeerReekingMonk (Deacon) on Jul 14, 2016 at 17:56 UTC
    I am not sure this is the best way, but you can run yourself again:

    BEGIN{ unless (defined $ENV{APPLEJACK}){ my $cmd = "env APPLEJACK=TRUEBLUE $^X $0"; print "Running exec $cmd\n"; exec($cmd, @ARGV); exit 0; }else{ print "APPLEJACK already defined\n"; } } print "STARTING " . $ENV{APPLEJACK} . "\n";
      if( ! $ENV{PERL_PERTURB_KEYS} ) { $ENV{PERL_PERTURB_KEYS} = 1; $ENV{PERL_HASH_SEED} = ...; exec( $^X, $0, @ARGV ); die "Failed to exec self: $!\n($^X $0 @ARGV)\n"; } ... rest of Perl code ...

      You can add the BEGIN block if you want to optimize away some wasted initialization work.

      Note that this does not take care of options being passed to Perl by the user, for example, if the script is being invoked like "perl -Imylib -i.old script *.ds". In a more likely scenario, you wouldn't be able to debug the script by just doing "perl -d script ...".

      - tye        

      Oh, now I notice that you've mixed your coding metaphors a bit.

      my $cmd = "env APPLEJACK=TRUEBLUE $^X $0"; ... exec($cmd, @ARGV);

      By using the 'list' form of exec, you've told Perl to interpret $cmd as only a path to an executable, not as some string to be interpreted by a shell as 4 different words.

      - tye        

      Also, for true relaunching, see Devel::PL_origargv. Your approach will generally work but will lose invocations such as

      perl -MSome::Module -Ilib -w script.pl

      Also, I think your approach would lose the -Taint flag, which is a bit more serious than the program just not working.

      Ah, thank you fellow monks for the insight. (actually, I tried tye's way, but it did not work then) Thus:

      BEGIN{ unless (defined $ENV{APPLEJACK}){ $ENV{APPLEJACK}= "TRUEBLUE"; exec( $^X, $0, @ARGV ); exit 0; # we actually never get here } } print "STARTING " . $ENV{APPLEJACK} . "\n";

      prints:

      STARTING TRUEBLUE

        Thx Everyone.

        The solution you gave indeed work.

        exec( $^X, $0, @ARGV );

        I was sure that whatever written inside a BEGIN statement is hapannig before everything else, so I'm not sure why my first attempt did't wok

        Isn't there a way to solve that without recalling the script again?

        By the way, I don't rely on hash to be sorted, but in this case I did my sort base on the values and not the keys.

        Since the values might be equal I got inconsistent printing while in earlier perl version the printing was consistent.

        Thx

        Guy

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1167787]
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (5)
As of 2022-12-07 23:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?