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

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";
[download]

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 ...
[download]

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        

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
[download]

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

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

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

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        

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";
[download]

prints:

STARTING TRUEBLUE
[download]

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