This is a long post, but I would caution you from "asking users questions that they do not understand".

I've done similar "preview" things before but usually on a higher level of user interface.

CASE A: For example with a complicated GUI configuration gizmo, hitting "apply" might summarize what you've asked me to do and the ramifications of the entire meta operation.

Maybe deleting feature 3 has some implication for feature 10. The user would have been aware of all of that when going through the GUI selections. I've built a "command stack" with actions, text descriptions and warnings as the GUI did its thing (the GUI forces the user's intent to result in commands that are consistent with each other and won't cause a "crash"). The "apply" button causes me to run down this stack and spew out the various actions that will happen and warnings so that this gets summarized in one place. When user hits "Do it", I actually run the commands on the stack.

CASE B:In other cases, I've had "print intent of what this will do" vs "do it" in lower level scripts. But that concept is built in as I write the code. And there is a flag to just "talk about it" vs "actually doing it" - these are advanced scripts for the support and development staff, not the end user. The ones like this I have so far actually assume that the "user" is capable enough to turn off a flag in the actual Perl source code if they don't want that done. These aren't "average users".

Presenting the user with a listing of low level commands that would have been executed is of dubious value. Ask the user a question that he/she can understand.

What's the purpose of some kind of preview? I would think:
a) summarize for the user what will happen in terms of functionality he can relate to, or perhaps
b) a "quick plausibility test": is there enough space for this relocation of a directory to work?

I would be thinking of a --preview that said something like "I'm going to move 10,123 files from X to Y and parition containing Y will have Z MB when finished", is more appropriate than some blizzard of rename,chmod,unlink low level commands.

More often a logging function is what you need for this low level stuff. Actually run the code and see what it does and write your code so that if it fails, you can run it again! If you have 200 of these low level commands, you won't understand from the preview whether it will actually work or not (might try to move some file that doesn't exist on line 176 or whatever - no way for your code to tell this without actually running it).

So although it is possible to override a core function, doing so for the purpose that you describe doesn't appear to me to result in any "user actionable information"...this is the common user refrain..."what the heck does that mean?". Don't provide information that is meaningless to the user and don't ask questions that they cannot answer.