Perhaps you could create a modified version, which doesn't really call rdist, but calls a perl program you write yourself to help with debugging - that way you can emulate using the real rdist without any of its side effects.

Of course, this would only work if rdist is the sole interface to the rest of the live environment... If there are other components which would be hard to emulate simply in Perl then you might need another solution.

There's no simulation mode. The alternative to running the script is - reading it.

Sounds tricky

As far as I understand this, you want to analyze what the program is doing but you don't want to run it.

Or you want to run it in a safe mode where any changes it might make are isolated from a real system - effectively running it in an emulated fashion - stepping through and saying what will happen without actually performing the steps of the program.

I don't know of anything that will do that so I'd probably start by doing this...

Working with a copy of the file on a non-production machine, I would read the code in depth and identify and research any code puzzling me. At this stage the Perl documentation would be indispensable.

If it uses modules then I'd be careful to try and understand how it declares instances and uses the methods in those modules and whether it used those modules in a non-standard way. I'd also want to understand what those modules do.

If it uses in-house proprietary modules, then I would have to seek documentation and/or advice, if any, for those modules.

By then I should be able to identify the areas where it might be changing the real time environment. I'm assuming this is the problem area for you.

Then I would test to check my research is correct. The extent to which you prepare for this is up to you. I have no idea whether the testing stage would require disconnection from the network or a complete backup of the test machine in case everything gets trashed but you may need to go to that level. Only you know that.

Running the code may involve providing some default values for some variables but by then I would have a good idea what was required.

It sounds like this script is deployed and running regularly.

What if you add a trace log so that the next time it runs, you can follow the flow of execution and see the data as it goes?
Simply write a little function called debug_trace, that will print $trace_file Dumper shift; You can then paste in calls to that at the beginning of each function plus sprinkled liberally around the area you're interested in. Use it to dump out execution flow tracing labels, along with variable contents so you can replicate the situation in a test environment.

Then you just need to wait for it to be run, and you can see what it did. Put more than enough detail in the first time, so you're less likely to have to go back in later.