Use a shebang of #!/usr/bin/env perl and let env use PATH to find what perl and then just ensure your running environment points to the right place. So long as you're not changing a system-wide config file (e.g. you do it in your account's .bashrc) it shouldn't affect what the OS uses.

Hello,

I work on so many different projects that having them each have their own perl install has been very beneficial. It is really simple once you understand the workflow.

Consider the following directory structure:

/home/me/projects
/home/me/projects/project1
/home/me/projects/project2
[download]

And designate that I want perl dedicated to each project. In each project directory, I have a ./src directory. In that directory, I have a perl source distribution extracted from a tarball downloaded from http://www.cpan.org/src/README.html. In that directory, I run:

sh Configure -de -Dprefix=/home/me/projects/project1/perl
make
make install
[download]

After the make install runs, there is a perl isolated from the rest of the system in the directory as specified in the configure command.

Next, I use a terminal dedicated for that project and set the environment variable PATH to look in the desired directory when I run perl at the terminal. I do this by making a script in the project's bin directory, and sourcing this script:

$ cat /home/me/projects/project1/bin/environment
#!/bin/bash
export PATH="/home/me/projects/project1/perl/bin:$PATH"

$ chmod 775 /home/me/projects/project1/bin/environment
[download]

Then every time I open a new terminal for this project, I source this environment script:

$ which perl
/usr/bin/perl

$ . bin/environment

$ which perl
/home/me/projects/project1/perl/bin/perl
[download]

Now you have a perl isolated to the given project that will not interfere with the system perl at all.

There is one other thing that you need to keep in mind: The CPAN configuration for this install. By default, when you run perl -MCPAN -e shell or similar as a non root user, perl will want to put the cpan configuration in /home/me/.cpan. This is okay, but when you have more than one local install of perl (say, project1/perl and project2/perl), using /home/me/.cpan for both will conflict. To remedy this, make sure to use manual configuration when running the given perl's CPAN configuration for the first time, and choose a unique place to store the CPAN configuration directory. I use /home/me/projects/project1/perl/.cpan.

And now you have a completely isolated perl ready to use for your project that will never bungle up the system's perl. To uninstall this perl, you simply rm -rf /home/me/projects/project1/perl.

This concept works for applications in general, especially on linux based systems. For example, the popular chat application pidgin has started to have problems connecting to yahoo because of configuration changes at yahoo. The pidgin folks have this problem fixed in the most recent version, but the apt and yum repositories don't have the most recent versions yet. So to solve this problem, you can install a more recent version from source in a unique area using the prefix option to configure, and launch that pidgin. Then when the apt repo gets the fixed version, you can apt-get upgrade the system pidgin and rm -rf the locally installed one.

Hope this helps!

#!/usr/bin/env perl
[download]

Cheers!

Update: Sorry Fletch. I didn't see your response before I replied.

Thanks for all the replies!

I just want to make sure I have it absolutely right:

1. Use #!/usr/bin/env perl in my scripts

2. Put a line in my Mac /Users/Me/.bash_profile that reads "export PATH=/usr/local/bin:$PATH"

Thanks for the other suggestsions. I don't have anything close to root access on the server so a symlink won't really work and I don't think I need more than one extra perl installation. The alternate shebang notation seems like the right fit for me.

Thanks again!

Sanjuro