Do I need the Perl bin directory in the PATH to run perl programs (on Windows)?

Question

Traditionally, I would just have C:\perl\bin in my PATH variable, but due to version conflicts I would like to keep different perl versions at locations C:\Perl-versionXY\bin and just execute my Perl scripts via directly invoking C:\Perl-...\bin\perl.exe theScript.pl.

This is actually to be run under an automated system, where we already directly invoke C:\perl\bin\perl.exe for all perl scripts. (But C:\perl\bin is also in the PATH.)

To facilitate different Perl versions side-by-side, I'd like to remove C-perl-bin from the PATH to make sure we don't ever see side effects from any Perl related PATH settings.

Is this supposed to work? What about modules that require additional DLL files (like LibXML, that requires the LibXML.dll in the bin directory of perl)??

I'll be using Strawberry Perl portable for the side by side versions. (Who's readme file mentions some PATH settings, but doesn't mention which is used for what.)

Answer 1

Provided that all the DLLs are in the same directory as the executable, it should work normally. If there is only one entry for Perl in the path, then the DLLs must be in the same directory as the executable (or are being found using some explicit logic) so you should be OK. When an executable loads a DLL, the first place searched is the directory containing the executable.

If you do run into trouble, one option would be to create a command file for each version. You could give these different names, like perl58.cmd, perl514.cmd, etc., put them all in a single directory, and put that directory on the path. In each command file, add the corresponding Perl directory to the path and then launch Perl with the command-line arguments:

setlocal
PATH=c:\perl58\bin;%PATH%
perl %*

Note use of the setlocal command so that the change to the path is not exported back to the command line window you're running the command file from.

Answer 2

I would caution that if you do not have the Perl bin directory on the PATH, and anything that you executes attempts to invoke program that lives in the bin dir without providing an explicit path (bad practice, but that doesn't stop it from happening) then you get failure, and depending on how that failure is handled, could manifest in problems that are subtle and hard to debug.

So I say, unless you have a very compelling reason not to add it (e.g. IT policy that makes it prohibitively hard and annoying to add to PATH), then add it.