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

I am porting a unix-based perl application to WinXP. My WinXP environment is polluted by a large commercial application that is beyond my control. This commercial app has three vintages of cygwin buried in it, the MKS toolkit, at least three perl installations, and numerous system and user environment variables.

To port my code, I've added yet another perl and cygwin. I've created scripts that clean up the environment before launching my code.

I have started writing a program to help wade through the mess. So far, it dumps the environment variables and some information from Config. I can imagine something much better. For example a program could parse perlrun, then look for perl-related variables in the environment, and explain them.

I welcome comments, pointers, suggestions, ideas, stories, or code that might help me along the way.

It should work perfectly the first time! - toma
  • Comment on RFC: Diagnosing Environmental Pollution

Replies are listed 'Best First'.
Re: RFC: Diagnosing Environmental Pollution
by rinceWind (Monsignor) on Jan 12, 2007 at 14:53 UTC

    An alternative approach, if you have the option of a build PC and a run PC, is to package your application with PAR::Packer, and so isolate it from the contaminated perl on the target machine.

    In terms of multiple perls on a Windows box, make sure the perl you want to use appears first in PATH, if necessary by employing a wrapper script. This will deal with command line invocations of perl. Check the file association for .pl file types, and make sure this is pointing to the perl you want and expect.

    --

    Oh Lord, won’t you burn me a Knoppix CD ?
    My friends all rate Windows, I must disagree.
    Your powers of persuasion will set them all free,
    So oh Lord, won’t you burn me a Knoppix CD ?
    (Missquoting Janis Joplin)

Re: RFC: Diagnosing Environmental Pollution
by xdg (Monsignor) on Jan 12, 2007 at 13:56 UTC

    Have you considered running one or more virtual machines to isolate these messy applications on the same hardware? It seems to me that might be easier/faster than trying to wedge yet another perl onto a box and avoid conflicts.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      I little influence over the user's machines, other than my application bits. Some of the users may have virtual machines already installed already. But I will have to run inside the machine that is already polluted, since my application is launched from the messy commercial app, and needs to interact with it.

      It should work perfectly the first time! - toma