The tale of associating .pl as an executable on Windows

First, I assume you installed ActivePerl 5.8+ installed. I also assume that you know how to modify safely the Windows Registry.

#1 In HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl
- Don't bother if the key doesn't exist.
- Remove Application value if there is one.

#2 In HKEY_CLASSES_ROOT\.pl
- Remove PerceivedType value if there is one.
- The (Default) value must be Perl.

#3 (x64-ONLY) Now do some verifications just in case. Verify HKEY_CLASSES_ROOT\Wow6432Node\.pl and make the value is the same than in its corresponding non-Wow6432Node key. Registry key reflection should kick in but if some 32 bits programs made modification to these keys, it could be different. Ahhh virtualization & reflection... :)

At this point, simply typing the name (including extension) of your Perl script will start it. For example, open a command prompt (64 or 32 bits as they should work fine for both) and type the (complete) name of your .pl script! Isn't it magical?

---

Now the true great trick is there:
If you want to have your .pl files searched through your %PATH% environment variable and to remove the need to type the extension at the same time, fix the %PATHEXT% variable by adding ";.PL" at the end (Or in the position you prefer for extension priority). Restart your command prompt and now you can simply type the name of your Perl script without extension. If you do not know how to modify environment variables, search in the System control panel. Note that this trick is applicable to any extension type that has a shell\open\command subkey. This fact is explained in online help of start (i.e. start /?).

Have fun!

---

Update: the following describe how to setup by using the cscript way. The problem with this method is that the command line arguments are not sent to the script for an unknown reason. I verified that cscript is indeed receiving the arguments. There must be a bug in ActiveState scripting engine. This section is kept for historical reasons.

#1 In HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl
- Don't bother if the key doesn't exist.
- Remove Application value if there is one.

#2 In HKEY_CLASSES_ROOT\.pl
- Remove PerceivedType value if there is one.
- The (Default) value must be PerlScriptFile. You may want to set the value to "Perl" instead. The difference is how the scripting engine is started. With Perl, c:\perl\bin\perl.exe is started; otherwise, cscript.exe is started and uses the ActiveState perl scripting engine. Why chose one to the other? Well the scripting engine permits you to have a nice property sheet on perl script files. :) I think it starts slightly faster. Maybe I'm just wrong. In theory, it'd add script debugging with VS2005 but for an unknown reason to me it doesn't work. Maybe the free version has been stripped down to remove this functionality. If you do so, step to #6 for the .pl verification only for x64 platforms, otherwise, you are finished but keep reading for second trick.

#3 In HKEY_CLASSES_ROOT\PerlScriptFile
- Set a nice description for (Default) value like "Perl Script File". What? You don't care? That's a very important step! :)

#4 In HKEY_CLASSES_ROOT\PerlScriptFile\Shell
Rename the Open subkey to OpenW and Open2 subkey to Open. By default, Open starts Wscript and Open2 starts Cscript. We want the reverse.

#5 In HKEY_CLASSES_ROOT\PerlScriptFile\Shell\Open\Command
- The (Default)'s value should be 'C:\WINDOWS\SysWow64\CScript.exe "%1" %*'. If it's wscript instead of cscript, you missing step #4.
- Change it to 'C:\WINDOWS\SysWow64\CScript.exe //Nologo "%1" %*'. This removes the copyright notice of cscript at start.

#6 (x64-ONLY) Now do some verifications just in case. Verify HKEY_CLASSES_ROOT\Wow6432Node\.pl and HKEY_CLASSES_ROOT\Wow6432Node\PerlScriptFile\Shell\Open\Command and make the value are the same than in their corresponding non-Wow6432Node key. Registry key reflection should kick in but if some 32 bits programs made modification to these keys, it could be different. Ahhh virtualization & reflection... :)