HOW TO SET UP A NETWORKED WIN32 ACTIVESTATE PERL

Update

These notes were written at a time when the ActiveState MSI installer refused to install to a UNC (network) path; it insisted on a path beginning with a drive letter. Since then this restriction has been removed and it's now possible to install ActivePerl directly to your UNC location. However, there are a few things I don't like about the direct install so I continue to prefer the technique described below. The problems are:

The installer insists in sticking an extraneous "Perl" into any install path you give it. I.e. if you tell it to install to \\fileserver\Perl you'll find the result in \\fileserver\Perl\Perl. And since \\fileserver by itself isn't a valid UNC path, there's no way to trick it into doing the right thing. If you're picky about not having a redundant or (at the least) overly long path to Perl, you'll end up using the reloc_perl script as described below anyway, and thus the direct install ends up buying zilch.

It remembers in the registry that Active Perl has been installed on this machine, even though the whole point was to install to a non-machine-specific location. I discovered this when I tried to install a local copy after the network one in order to benchmark them against each other. The installer "knew" that Perl was already installed and refused to let me install "again". By the same token, the direct install will leave a program group folder on the installing PC. Not everyone will care about these warts, but the install-copy-modify-uninstall procedure below leaves the host PC entirely pristine, i.e. the same as it was before and no different from any other PC in your network vis-a-vis ActivePerl. And that's the goal.

However, if you want to keep it really simple and don't care about the above, a potential command line (as contributed by David Baird) would be something like:
start /wait msiexec /i ActivePerl-XXX.msi TARGETDIR="\\fileserver\netperl" ADDLOCAL="PERL_FEATURE,PPM" /qr /l instlog.txt
I don't know whether the GUI install allows a UNC path to be specified or browsed to.

Installation

This is really quite simple: we will install ActivePerl to a local drive, copy it to a network drive, use the reloc_perl script to update the network copy's understanding of its new location, and uninstall the local copy.

First, create a share on the appropriate server, e.g. "\\fileserver\netperl". This is where your network perl will be served from. Make sure it's writeable from your PC as yourself. You may want to make it read-only except for those who will be maintaining Perl. It's ideal if your fileserver is a UNIX system running Samba/TAS or a NAS device because any of these will be capable of translating symbolic links, and this is of great value for shared maintenance between UNIX and Windows Perl setups as described below. A Windows file server will work too, you just won't be able to play games with symlinks.
Attach the share to any open drive letter; we'll use P: here. The mount is strictly temporary, so you might want to uncheck the "Reconnect at logon" box (or use /persistent:no at the command line).
Go to the ActiveState web site (http://www.activestate.com/) and download the latest Perl-Win32 binary package. Get the standard MSI-installer version.
Install AS Perl to X:\TmpPerl where X may be any local drive letter and the TmpPerl part is literal.You can do this either at the command line with something like:
```
 
	start /wait msiexec /i ActivePerl-XXX.msi TARGETDIR="C:\TmpPerl" ADDLOCAL="PERL_FEATURE,PPM" /qr /l instlog.txt
```
or with the regular GUI. If you use the GUI, remember to decline all options in the Choose Setup Options screen. None of the other systems on which this Perl will run will have (or need) registry customizations and there's no reason to make the install system different. The whole idea is to make a Perl that doesn't depend on any local settings. I recommend suppressing installation of the AS add-ons such as PerlScript and PerlISAPI as they aren't typically useful to a network perl. Similarly, you may choose to suppress installation of the example programs.
Copy (using, say, drag and drop within Explorer) the entire install area under C:\TmpPerl to P:\. At this point we have two identical copies of the new Perl build, one local and one on the file server. If you did everything right to this point, each of the following commands will work (which is good) but will show the same result (which is bad):
```
	X:\TmpPerl\bin\perl -V:prefix
	\\fileserver\netperl\bin\perl -V:prefix
```
We still need to tell the network copy its new address, which is done using the reloc_perl script.
Unmap the drive letter P:, partly so you don't forget later and partly to ensure we only access the network version via its UNC path. We'll use the local Perl to modify the network copy.
Run the following command, suitably modified for your pathnames:
```
	C:\TmpPerl\bin\perl C:\TmpPerl\bin\reloc_perl -a -i -v //fileserver/netperl
```
The reloc_perl script is really trivial in concept; all it does is search through the files under the specified directory (the perl install area) and replace string XXX with string YYY. Kind of like sed except it can operate on binary files too.
It's your call whether you want to specify a Windows-style string "\\fileserver\netperl" or UNIX-style "//fileserver/netperl". There are arguments either way and it tends to be a religious issue. I prefer forward slashes and have only tested with them. And in fact I've gotten feedback from a user (see below) that no matter how you specify the location, the components of @INC are in forward-slash form.
Now rerun the -V:prefix command above. The network copy should now report that prefix=//fileserver/netperl. If so, everything went right and we're done. If not, well, you get what you pay for. There was probably an error message along the way with details.
Go to the Control Panel and uninstall Perl from C:\TmpPerl. Your host PC is now back to its original state; it has no knowledge of Perl being "installed". This is a feature.
Optionally, add \\fileserver\netperl\bin to your PATH manually, using Control Panel. Like all UNC PATH entries it should go towards the end of the %PATH% variable and should be added as part of the user path. This is one setting which would need to be made per-client if you use it at all - triggers and other scripts can be made to not depend on PATH. If you do need to make this setting on client machines, the registry entry is HKEY_CURRENT_USER\Environment\PATH and it can be easily set as part of CC installation or in many other ways.

Slash Style

In late 2003 I received the following note from David Baird.

I tested both forward slashes (/) and backslashes (\) for the new location of Perl, and found that in both cases, the @INC is written with forward slashes (/). Also, backslashes are written to the .bat files in the Perl directory for the perl.exe command. It seems not to make a difference what you enter.

Binary vs text relocation

UNIX perl builds have historically compiled the value of @INC into the binary program, so localizing them would require recompilation or binary editing. ActiveState Win32 perl, however, has a feature such that it autodiscovers its install location at runtime. Thus, though reloc_perl is capable of modifying binaries, on AS Win32 builds it should only need to modify text files such as Config.pm. I'm not sure if this autodiscovery is a property of AS perl or a feature of all recent (5.6.1+) Perls.

Interop and Maintenance

If using this configuration in combination with a UNIX-aware SMB interop solution such as Samba, and assuming you have a UNIX Perl installation too, module maintenance can be greatly eased by creative use of symlinks. Let's say you want to use the ClearCase::ClearPrompt module. First install it to your UNIX perl. Let's say it ends up in /usr/local/lib/perl5/site_perl/5.6.0/ClearCase/ClearPrompt.pm. Now, on the UNIX box, go to your Win32 perl install area and symlink .../site/lib/ClearCase to /usr/local/lib/perl5/site_perl/5.6.0/ClearCase. From now on you can install updates to this module (or in fact to any modules in the ClearCase:: namespace) on the Unix side and they'll automatically apply to the Windows perl as well. You can symlink individual files or whole hierarchies as preferred. Module updates must be handled from the Unix side in this scenario, because Win32 perl can handle Unix line termination style while the reverse is not true.

To run scripts with a networked Win32 perl, I do not recommend using pl2bat or registering the .pl extension. Both of these present maintenance headaches. Instead, I use a tiny redirector program as follows:

@echo off
\\fileserver\netperl\bin\perl \\server\share\program %*

If you play your cards right this can point to the exact same script you use on UNIX. I.e. \\server\share\program can be an SMB access to the same file found via UNIX NFS as (say) /usr/local/bin/program. In future, when you update the UNIX script it will take effect on Windows automatically. The redirector itself should never need maintenance because it's 100% boilerplate.

Configuring and using the CPAN module or PPM (the ActiveState install mechanism) is left as an exercise for the reader. Be aware that both need some special setup to work within firewalls. I have some notes on PPM setup contributed by David Baird.