But go ahead guys. Keep on declaring any code that does not meet your personal standards for cleanliness or elegance to be "worthless" and watch the number of IT managers who refuse to let Perl anywhere near their shop grow.

1. The desire to rewrite rather than modify is not limited to perl programmers.


2. Shit code is shit code. Good code is good code. I know. I've written both. And one of the main differences is that when it comes time to make changes and add features, the shit code is sheer agony and the good code is surprisingly easy.

If the new reports are only trivially different from the existing reports, the OP might be able to tweak the program to meet the needs. Some parts of the program may be salvagable.

But a system that is contained within one 8000 line file with few or no comments, doc, no warnings and no strict, and lots of global variables named in the form g_xxx is almost certain to be shit code. It is hard to imagine anyone who cared writing anything decent that matched this description.

But it probably is a mistake to condemn it without seeing it. Lori, you might want to try and get some help with this. This is one place. Another might be at a meeting of your local Perl Mongers group. http://pm.org.

The advice given above about learning how your webserver works is excellent, especially the log files, especially the error logs because anything you output to STDERR (eg warn 'something') ends up there instead of in the webpage.

--Bob Niederman, http://bob-n.com

All code given here is UNTESTED unless otherwise stated.