What I learnt from moving old perl…

One of my tasks this week was moving bookings.ecs.soton.ac.uk to a new home. Bookings was perl cgi software written in 1996 by Julian Field to manage the booking of computers in our electronics and computing labs. It is completely bespoke from a time before perl’s CGI module let alone a reusable open source solution a general resource booking problem. It previously lived on one of our internal “DNS and misc” servers called stork which has been due for decommissioning for a few years now. The problem was stork is an old solaris 8 box (horrible setup)  running perl 5.6  and we were moving to Linux and perl 5.10. More worryingly the code was written for perl 5.003 several people had tried to move it previously with little success. My perl is fairly good but my perl history isn’t great what follows is a few old dark arts mainly lost from the annals of the web which I thought I would share for the benefit of anyone else who has to move old code to pastures new.

1. My first tip is stay calm. The perl community is very proud of how backwards compatible it is and so very few of your problems are likely to be from changes to the syntax or core libraries. I only had to make a few very simple changes but the debugging process was a little tricky. Back in the day perl strict was not in common use and the now accepted good practices had not been laid down or were not proliferated widely across the web. That means there will be unfamiliar syntax and a distinct lack of debugging information.
2. #!/usr/bin/perl the opening gambit which foxed me for nearly 20 minutes. On the solaris system I moved from perl lived in #!/usr/local/gnu/bin/perl the apache log reports file not found and script terminated prematurely. The file which was not found wasn’t actually the perl interpreter not the .pl file. I mistakenly assumed my apache virtual host configuration was wrong. The premature termination means because the interpreter wasn’t found the script crashes before printing http headers. All I had to do to fix it was go through each file changing the #!/ line.
3. Back in the day there was a $* variable in perl. When $* = 1 regex matches over multiple lines. It’s the only piece of perl syntax which was no longer supported in the whole code base and the error log even told me as much. The problem then became working out what it was $* actually did. Its not that easy to google and I did not find helpful results. In the end I pulled an old perl textbook off the shelf and found the explanation straight away. The solution is remove $* and add the /s modifier to the regex.
   Before:
   $* = 1;
   $foo =~ m/booking room/;
   After:
   $foo =~ m/booking room/s;
4. opendbm versions. I had never head of opendbm but its actually quite a neat tool. It lets a perl program sync a hash with a file, bookings was using it instead of a database. opendbm kept reporting “unable to open file”. I made the files chmod 777 but it still didnt work. After nearly 2 hours of debugging I finally realised the internal syntax opendbm was using had changed from the old version so I couldnt open my old data. Not a problem no one cares about past booking anyway. Simply backup the bookings file and delete it and the script creates a new one no problem.

And that was it, simple as pie…. pie which took most of a day to cook. But then again what language could you take 16 year old code and move it across operating systems and interpreter versions and have it still working by the end of the day. I was talking to some friends in the pub and we concluded “not many”. Java would have made you wish for death, even if you had the source code. Well done perl, well done Jules and well done me.