NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Installing into locations other than C:\strawberry (Score:1)
I still don't see where the difficulty is [perl.org]. You can skip the "Set up $ENV{PATH}" step in the setup for other locations (like, say, C:\Program Files\Strawberry Perl) and supply a batch file that sets up a "Perl Console" which has the correct $ENV{PATH}:
Re:Installing into locations other than C:\strawbe (Score:1)
2. CPAN.pm and another config file have specific paths (I've made a path-agnostic CPAN.pm for the next release as a first stage).
3. I refuse to limit people to only be able to have working Perl applications if they launch a "Perl Console".
Perl apps should Just Work, regardless of how you run them.
If I do Start... Run... perlapplication, and it fails, it's not good enough.
I'm sure there's a better solution that DOE
Re:Installing into locations other than C:\strawbe (Score:1)
The Win32 Makefile does not enable relocation by default because Perl has always been relocatable on Win32. It's only some modules that aren't without some patching. I've used Perl since 5.6 on Windows in various directories and never encountered any problem that wasn't related to badly written Perl modules that couldn't cope with whitespace in directories.
Double-clicking any Perl program will work even if Perl is not in $ENV{PATH} on Windows, because you (presumably) set up the file association between the Strawberry perl.exe and .pl files correctly upon installation. So the need for manipulation of $ENV{PATH} is lessened. This is of course only a stopgap until you (optionally, but by default) set up $ENV{PATH} correctly for any location and not only for c:\strawberry.
Reply to This
Parent