On Tue, 21 May 2002 12:57:34 -0400 (EDT), Keith Beckwith
<[EMAIL PROTECTED]> wrote:
>Windows DOES however recognize the .pl file extension as something that it
>should be able to do something with though and goes in search of something
>to 'open this file with and make it do something'. It's at this point that
>windows finds somewhere (in itself, outside, not sure) perl and decides to
>reinstall/reconfigure it. It was at this point that it was setting my
>libpath variable to
>C:\p4view\Apps\ActivePerl\MSI\data\ActivePerl\Perl\site\lib as opposed to
>the C:\perl\site\lib which is what it really was. Note, this is a compile
>time variable, so basically it looks like windows was being helpful by
>recompiling perl with the 'correct' settings for me :p
The Windows installer (MSI) does this if you have updated some of the
bundled modules via PPM. It then thinks it needs to "repair" the broken
installation and extracts the files again (MSI keeps a copy of the MSI
files around, so it can access them again). But it doesn't run the
configuration script again, which would adjust the installation paths etc.
>anyway.. the fix was to go into file types and set 'open' with perl.exe as
>the default, directly after a proper install.
The reason this fixes the problem is that it gets rid of the little
registry value that MSI sneaked into the .pl association to allow it to
run the "Repair" action. You can also just remove the value with a little
Perl script:
require Win32::Registry;
$::HKEY_CLASSES_ROOT->Open('Perl\shell\Open\command', my $command);
$command->DeleteValue('command') if $command;
Note that this only deletes the (undocumented) "command" value under the
"shell\open\command" key, but not the key itself (nor the default value,
which is needed).
This is what ActivePerl 632 will be doing before the installation
finishes. :)
Cheers,
-Jan
_______________________________________________
Perl-Win32-Users mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
