Today I was asked to help out another team with some legacy Perl code. It's some seriously awful crap. The problem is not so much the coding style (although that could use work, too) as the way they've setup their library paths. And by "they", I'm referring to programmers that have long since left the company.
You see, they've got the shebang lines hard coded in a bunch of files (which are, ultimately, fired off from, and returned to, a Java process). The problem is that the original system it was designed for assumed Perl 5.004_01 in /usr/bin and Perl 5.005_03 in /usr/local/bin. Different, but related, scripts require specific versions, due to the location of in-house libraries. Then, the 5.004_01 scripts actually unshift the Perl 5.005_03 site_lib into the @INC array. So, now we've got a mix of two different versions of Perl using libraries from each other's site_lib.
Lovely. And breaks horribly if Perl is installed differently on a different system (as it was today).
"Well, Dan, why don't just move all the in house code into Perl 5.005_03 and forever rid yourself of Perl 5.004_01 altogether? Or, better yet, upgrade to Perl 5.8.x? You know, one Perl to rule them all and all that?"
I'm glad you asked. The answer is simple - compatability. I don't know for sure, but I get the distinct feeling (based on some past experiences here) that the code that relies on 5.004_01 breaks in newer versions of Perl. The tests we ran today more or less confirmed that by tinkering with shebang lines and forcing certain versions of the interpreter on the command line.
What those issues might be, I can't say for certain. I can't see any other reason for this situation to exist, or to have ever existed in the first place.
"So, how about a rewrite?"
Not enough time.
