On Thu, Aug 27, 2009 at 12:14 PM, John R. Hogerhuis<jho...@pobox.com> wrote: > On Wed, Aug 26, 2009 at 9:55 PM, Adam Kennedy<a...@ali.as> wrote: >> The problem with multiple installs has always been (and continues to >> be) the PATH elements. >> > > My $.02: no offense to anyone but it's hard to take any installer > seriously that wants to install to only a fixed spot. > > I spent some time grepping through the build to see what all is needed > to factor out the path to make my own binary Perl distribution that > could install anywhere the user requests.
There are several related issues, so it's important to distinguish between them: (1) Having multiple "perl.exe" executables in PATH means that any code that just shells out to "perl" instead of $^X runs the wrong perl.exe. This is not a Win32 specific problem, but seems to crop up there because installers change PATH, whereas on *nix, it's the users who tend to change PATH and are at least conscious that they are making a choice between perls. (2) Installing to a known spot is a way to avoid installs to a path with spaces in it. While in theory, perl shouldn't care about spaces in the path, in practice it causes problems if people execute shell commands without proper escaping. And while there is system($cmd,@args) to help with that, that doesn't help code with backticks. (C.f IPC::System::Simple, Capture::Tiny and other alternatives) (3) Hardcoded paths in perl or core modules. Presumably, this is "solved" with relocatable @INC paths, but I don't know how stable those solutions are. Other issues, anyone? -- David
