>>Assuming the various versions of Perl weren't configured by monkeys typing random characters, Unfortunately, that's the way it's been for all of my clients. :)

Also, I need to have a central repository for the custom libraries. It's not a good idea to take on the maintenance of updating code on 11 platforms if you do not have to.

My system was initially setup for a hybrid environment of 5.005_03 and 5.6.1. I have to reference some custom libraries that were written for 5.005_03. Furthermore, I have to backup to make sure my system fully supports 5.005_03 on all 11 platforms.

Note: The system is centrally located, so any changes on the UNIX/Linux side of the house will affect all of those platforms.

After making changes on aix due to referencing higher versions IO 5.6.1 library problems, my system started working correctly on Perl 5.005_03. Solaris is still running Perl 5.6.1. That is all it has installed. Other than the old Perl executable I previously mentioned.

So,when I tried running the same code on Solaris, it barfed because of the Perl 5.6.1 system is expecting Perl 5.6.1 versions of IO to be in PERL5LIB. Perl is in many different locations on the various UNIX/Linux platforms, but in the same place for the 5 Windows + Netware platforms.

One question is can I have Perl switch on the libraries on the fly with a BEGIN statement? Something like:

    use Config;
    $PLATFORM = $Config{'osname'};

    if (($PLATFORM =~ /^MSWin32/i) ||
        ($PLATFORM =~ /^solaris/i)) {

        # use Perl 5.6.1 libraries
        BEGIN {

            @PERL_SHARE = (
                    "/foo/custom/perl/lib/Custom_mods5.6.1",
                          );
            unshift(@INC, @PERL_SHARE);
        };
    }
    else {
        # use Perl 5.005_03 libraries
        BEGIN {

            @PERL_SHARE = (
                    "/foo/custom/perl/lib/Custom_mods5.005_03",
                          );
            unshift(@INC, @PERL_SHARE);
        };
    }
[download]

-P0w3rK!d

That won't work as-is because both BEGIN{} blocks will be executed before the if statement is even compiled.

If performance or memory is a consideration, unless you are using %Config for other things as well, you would be better off using $^O to test for the OS. It contain sthe same info as $Config{'osname'} but without the overhead of loading Config.pm.

Also, why are you putting a single scalar into an array and then unshifting the array?

This ought to come pretty close to what you are trying to do I think. (NB:untested)

BEGIN{
# UPDATE: Corrected typo pointed out my [Abigail-II] below.
    unshift @INC, $^O =~ m[^(?:MSWin32|solaris)$]i
                ? '/foo/custom/perl/lib/Custom_mods5.6.1'
                : '/foo/custom/perl/lib/Custom_mods5.005_03';
}
[download]

Though that is probably better coded as

(Also partially untested)

BEGIN{
    use lib $^O =~ m[^(?:MSWin32|solaris)$]i
                ? '/foo/custom/perl/lib/Custom_mods5.6.1'
                : '/foo/custom/perl/lib/Custom_mods5.005_';
}
[download]

---

Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.

I would discourage that kind of test. Once you update the version of perl on Solaris, for example, you're screwed... I'd rather go for checking the version of perl.

Of course, the best thing would be a clean install. See my other post.

@ENV? What's that array going to do?

Also, there's no point in making a BEGIN block that contains just a lone use statement. A use statement is already executed as soon as it's compiled - putting a BEGIN around it isn't going to speed it up - it won't execute it before it's compiled.

Abigail

The BEGIN block was someone elses code that was never "adjusted". I like the way you did this. Thanks. I will adopt your wisdom into my code :) -P0w3rK!d

Also, I need to have a central repository for the custom libraries.

Sure, but only custom libraries should be there. There should not, for example, be copies of core modules in there. That would create headaches.

I have to reference some custom libraries that were written for 5.005_03

If the custom libraries will also run under more recent versions, I don't see the problem. If they won't, then of course they have to be fixed so that they will.

So,when I tried running the same code on Solaris, it barfed because of the Perl 5.6.1 system is expecting Perl 5.6.1 versions of IO to be in PERL5LIB

Yes, that's what it should expect. If that system has 5.6.1, then its PERL5LIB should be the one for 5.6.1 also. That's basic consistency. If you are changing PERL5LIB to point to a central directory, then all the systems using that directory need to have the same version of Perl. Otherwise, if they have different versions of Perl, they must also have different versions of PERL5LIB.

what would the best practice be?

The best practice would be to write your code so that it doesn't matter which version of Perl it runs under, simply by not relying on version-specific hacks.

I still don't understand your problem with modules; for any given module you are trying to use, there are three possibilities: it will run fine under either version of Perl, it won't run at all under some versions, or a different version of it is needed depending on the Perl version. In the first (ideal) case, there should be no problem. In the second case, it should be obvious that you can't use that module. In the third case, you must install the right version of the module on each system for the version of Perl that is there.

In no event should any of your code ever be looking for specific versions of a module. Write your code generally, without version-specific hacks, so that any (supported) version of the module will just work.

(If the module changed its API between versions, you should either not use that module (my first inclination) or if you absolutely must use it write a wrapper module so that you don't have to use it directly; install the correct version of the wrapper module on each system for the version of the wrapped module that is there. All versions of the wrapper module should present the same API to the rest of your code.)

Some of my assumptions may be way off base; I had a hard time following your description of your problem, but as best I understand it, it _sounds_ like the custom modules aren't really your problem, but some core modules that you (or the custom modules) use. It sounds from some parts of your explanation like some installations are getting versions of the core modules that are wrong for the version of Perl and/or for eachother. This implies that someone at your site has messed with the core modules in an inappropriate way. It's hard to be more specific without knowing more details about your setup, except to say that each installation of Perl should have its own installation of the core modules, and any custom modules that are to be shared across multiple versions of Perl must be able to work correctly with whichever versions of Perl (and thus the core modules) they happen to get.

---

for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc'
.'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$
p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}
[download]

>>Some of my assumptions may be way off base;


Some are, but thanks for working through the problem for me in an unbiased manner. You helped me realize that the problem is directly related to IO::handle, Filehandle.pm and the custom library "logfile.pm", which references them.


>>I had a hard time following your description of >>your problem, but as best I understand it, it _sounds_ >>like the custom modules aren't really your problem, >> but some core modules that you (or the custom modules) >>use. This implies that someone at your site has >>messed with the core modules in an inappropriate way.


Perl is in bad shape on all of the UNIX systems. I am trying to rectify that.


Thanks for your help :)


-P0w3rK!d