tilly: you raise a good point. This script is something that I was assigned to write and thought I would offer to others in the event that they were called upon to perform a similar task. I can see a valid reason for such a script if one has a proper development environment set up:

1. Development area: Here's where geeks like myself play around and create marvelous works of art. Here, we can experiment and do what we will.
2. Staging: Here's where the development scripts get rigourously tested. QA occurs here (and that should be Quality Verification, not Quality Assessment, but that's a personal rant). The environment here should be an exact duplicate of what's in production.
3. Production: Duh.

Properly, a script such as mine should only be applied in the migration from development to staging. For example, I often have this at the top of my code:

#/*
use warnings;
use CGI::Carp qw( fatalsToBrowser );
use CGI::DebugVars;
my $debug = CGI::DebugVars->new;
#*/
[download]

Later on, I'll have individual lines like this:

print $debug->table( ORDEROBJECT => $order ); #//
[download]

If I am copying over twenty programs, this script will automatically comment out those lines (amongst others) while simultaneously copying the code to the proper area. The problem with my code, IMHO, is not the code itself, but our lack of a proper staging area that perfectly mimics production. If, however, such an area exists and one is copying 73 programs to it, going through those programs and commenting out "use warnings" or "fatalsToBrowser" statements all over the place is a sure recipe for missing a few. With a tag-based system, they are much easier to catch.

Your turn :)

Cheers,
Ovid

Update: Both dws and tilly are right. I did miss the point of tilly's post. Sigh.

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.