Perl adds an external seed for reproducible random behavior

A failure influenced by random choices can be difficult to investigate when each run takes a different path. Changing the program to supply a seed is one answer, but that requires editing its initialization. Perl 5.37.3 adds PERL_RAND_SEED, an environment variable that can control the seed used by implicit random-number initialization or by a no-argument srand() call. The development release notes introduce it, and the release history records August 20 as the release date.

The scope of the guarantee is deliberately limited. This is a mechanism for making comparable runs of a particular executable, with other circumstances held equal. It does not define a portable sequence that an application can preserve as expected output across interpreter versions and architectures.

Seeding normally happens without a declaration

The srand documentation shipped with this version explains that the first rand call implicitly seeds the generator if the program has not called srand explicitly. Normally this initialization makes a best effort to obtain a suitable seed. Calling srand() without an argument also asks Perl to choose the seed.

An explicit argument is different. A program can call srand($seed) to select its seed directly. The new environment variable addresses the paths that otherwise choose one automatically. It therefore makes some existing programs easier to investigate without replacing their random-number calls or modifying their source.

env PERL_RAND_SEED=31415 perl -e 'print rand(), "\n" for 1..4'
env PERL_RAND_SEED=31415 perl -e 'print rand(), "\n" for 1..4'

These commands show two invocations of the same program under the same environment setting. They should agree for the same Perl executable when other factors are equal. No particular sequence of decimal values belongs in the example because the interface does not specify that sequence across implementations.

I like this for investigating small Perl transformations that use randomness indirectly. A process-level setting gives the investigation a controllable input without making the source change part of the experiment. That fits my preference for keeping one-off text programs short while still being able to explain their behavior.

The environment value is read at startup

The function documentation says Perl reads this setting once during process startup. Assigning a different value to the environment from inside the running program does not reseed that process. This matters because a debugging session can otherwise appear to change the seed while leaving the generator's state unaffected.

The documented value is a non-negative integer. Its exact mapping to generator initialization remains unspecified. Different values should produce different results, but the environment value is not a published encoding of every part of the internal random state. A caller should not infer an algorithm from a sequence observed on one machine.

The runtime manual also explains how the setting relates to forks and threads. Perl derives seeds deterministically while allowing the application process and its forks or threads to have their own seeds. The intention is to reproduce the program's random behavior across comparable runs without requiring every execution context to share one identical seed.

That does not make scheduling deterministic. The manual qualifies repeatability with the assumption that everything else is equal. If the program changes the order in which work consumes random values, a fixed initialization setting cannot by itself establish that corresponding operations see corresponding values. It supplies control over random initialization within the documented execution conditions.

Debugging repeatability is narrower than stable test data

The runtime manual explicitly says the variable is for debugging and performance measurements, and not for stable testing. Its guarantee covers a particular Perl executable producing the same results on repeated comparable runs. It makes no promise that another release or architecture produces the same stream.

A test that asserts an exact list of random outputs would therefore rely on more than this interface guarantees. An application with an externally specified sequence needs a generator contract that specifies that sequence. An investigation that asks whether two runs follow the same random choices within one interpreter has a different requirement, which this variable is designed to address.

The release also permits the feature to be disabled at build time through the NO_PERL_RAND_SEED configuration definition. The runtime manual says the variable is ignored when Perl runs setuid or setgid. These qualifications are part of the mechanism, so an environment assignment alone does not establish that every Perl executable will honor it.

My preference is to record the executable and the setting together when using this facility to compare behavior. The environment number alone does not contain the compatibility promise. The useful comparison is between equivalent invocations of the same implementation under controlled conditions.

The August snapshot also repairs platform behavior, including Windows timestamps that failed to account for daylight saving time in some cases. Its random-seed addition is more specific than a general reproducibility claim. It gives implicit generator initialization a controllable startup input, with a guarantee intentionally bounded to the executable and execution conditions used in the investigation.