nimdokk has asked for the wisdom of the Perl Monks concerning the following question:

I am in the midst of porting a custom module as well as some boilerplate code that we currently use on a Unix box to help us run an automated file transfer system. Primarily it connects the Intel side of the house with the Unix side (and vice versa). Even with an off the shelf solution, we still need to customize the some of what gets down (i.e. zip/unzip, de/encrypt with PGP, and so forth). Currently on the Unix side we are running everything with Perl programs. The guts of which is a module that I have put together. There is also a template of boilerplate code that incorporates the basics of what we need down with a minimum of customization on an as needed basis. On the Intel/Windows side, we also need to do some of the same type of work on a per transfer basis but at the moment it is in Batch scripts (which in my opinion are the weakest link in the whole chain). I am investigating using Perl on the Windows side and have had good luck so far and hopefully will be able to move into our test environment by the end of the week (if not sooner).

In porting the Unix code over to Windows, I have learned a few new tricks that will also help make the Unix code better. However, given some of the differences that need to be put into the module for use on the Windows side, I am wondering about issues of maintainability between the Unix and Windows versions of the code. Only 3 of the routines used in the module need major revisions in order to be useful on the Windows side of the shop. I think maybe I'm looking for some direction in keeping the modules reasonably consistent across the two platforms.

The question may have more to do with personal preference or style I suppose than anything else, but I'm curious to see how others respond and if anyone has pointers for a direction that I can look so that the code is fairly straightforward for someone else to be able to maintain if/when I should leave this position. Any thoughts would be appreciated.


"Ex libris un peut de tout"


"Ex libris un peut de tout"

Replies are listed 'Best First'.
Re: Of Perl Ports and Maintainability
by dragonchild (Archbishop) on Jul 29, 2003 at 17:59 UTC
    A few of the obvious points:
    1. Use modules for anything you would drop into the OS for. File::Spec, File::Copy, etc. (It turns out that File::Copy is sometimes faster than cp, to boot!)
    2. Don't use %ENV. Ever. Not only is it potentially insecure and undependable, it's also implemented differently on different systems.
    3. Don't expect to be able to run against STDIN and STDOUT interactively on Win32. You might have to telnet to yourself to have a terminal window.
    If you keep each component really simple, you might be able to get away with very few blocks of
    if ($^O eq 'Win32') { } else { }

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      if ($^O eq 'Win32')

      is incorrect. use

      if( $^O =~ m/Win32/ )

      instead. some windows operating systems report 'MSWin32', while others report 'Win32'. take the safe route. see Re: Re^2: Prune File Find search for a little more detail.

      ~Particle *accelerates*

      I've noticed that about File::Copy on Unix, my benchmarks have it copying a set of files almost twice as fast as cp or an off the shelf tool. And given what I've learned thus far in the port process, I'm going to go back to the Unix side and change those as well to use File::Spec. As for the environement hash (on Unix) I can't get away from it. Doesn't matter on Windows though. I've done my best to try to make %ENV safer. I'll take a look at using having the routine check the OS version and do work based on that. Thanks for the input.


      "Ex libris un peut de tout"
        As for the environement hash (on Unix) I can't get away from it.

        That's not the attitude I would take. The %ENV hash can be replaced very easily with any one of the Config modules on CPAN. And, in fact, should be replaced with those. By doing that, you remove a huge area which is OS-dependent. It also removes a lot of the maintenance headaches for you. I would seriously look into doing that.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Re: Of Perl Ports and Maintainability
by adrianh (Chancellor) on Jul 29, 2003 at 20:15 UTC

    I think the most important advice would be not to have separate versions of the same code for each platform. Isolate the platform-specific code as much as possible (maybe into a separate module) and switch in in and out by checking $^O.

    The biggest cross-platform maintenance nightmares I've come across are when people alter code on a platform by platform basis. Suddenly you have two separate codebases to update every time a bug is found.