You can override builtin functions: http://docstore.mik.ua/orelly/perl/cookbook/ch12_12.htm and http://docstore.mik.ua/orelly/perl/prog/ch05_02.htm#PERL2-CH-5-SECT-2.2. Nothing difficult in making them conditional (call of the CORE:: version or printing depending on switch) and even caching (i.e. concatenating to a string that is eval'd eventually and that uses the CORE:: version of the function).

Hi jethro,

I do know that it's possible to override core functions and have done so, much to the annoyance of Tom Christiansen, whose "Advanced Perl" seminar I took at USENIX a couple years ago (direct quote: "Don't ever do this unless your sole purpose is to prove how cool you are.")

Besides the fact that I would also like to override File::Copy and File::Path (and possibly functions from other core modules) this approach is more work and probably more bugs than using a previously-written community-tested CPAN module. :-)

-jh

So it sounds like you recognize the impracticality of a "solution" that involves overriding core functions and modules -- even though the "dream module" that you describe in the OP probably couldn't be implemented any other way (as near as I can tell).

Yet at the same time, it sounds like you are hoping to avoid the alternative of altering every line of existing code (or including a bunch of repetitive stuff with every line of new code) involving any sort of file-system change, so that it can be made conditional on the value of the "preview" option.

Alas, I don't think there's a third way. The best you can do is find ways to minimize the overhead of making all those file-system operations conditional. Ideally, this is something you plan out for before actually writing any code for the given application.

In that regard, my personal preference would probably fall toward a module that builds a stack of operations, then, you just check your option setting once at the end of the process, to decide whether to print the stack, or execute it, or present it for approval, or store it as a script file, or ...

If you're adapting existing code to provide this new functionality, it means editing every line that does a file system call, to turn that into a call to the module's "push" method -- no way around that. If you're starting a new app, it's not that much overhead to write $stack->push( "rename", $arg1, $arg2 ); instead of rename $arg1, $arg2; -- maybe there are ways to make the method call even easier.

You could generate a program.

push @ops, "rename(".text_to_perl_lit($file_from).", ".text_to_perl_li
+t($file_from).");";
...

my $program = join '' map "$_\n", @ops;
if ($preview) {
   print($program);
} else {
   eval $program;
}
[download]

Add error checking to liking. But that might make the preview unreadable. An alternative would be to provide your own operations.

sub xrename {
   if ($preview) {
      print(...);
   } else {
      rename(...);
   }
}

xrename(...);
[download]

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.

if ($preview_mode) {
    print <<EOT
rename $file_from -> $file_to
chmod 0777 $file_to
unlink $temp_file
EOT
}
else {  
  rename $file_from, $file_to or die "Could not move file: $!\n";
  chmod 0777, $file_to or die "Could not chmod file: $!\n";
  unlink $temp_file or die "Could not delete file: $!\n";
}
[download]