There are a couple of solutions, of which the most elegant is to make sure that the directory containing perl.exe is placed in the system path.
I imagine you know how this is done, but for others I'll iterate the process under WinNT 4.0. Start->Settings->Control Panel->System, select the Environment tab, click on System Path in the System Variables box, click in the value box, hit the end key, add ';d:\perl\xxx\bin', replacing that with the fully qualified path to the directory containing the Perl executable, click Set, then OK.
If you're not an administrator on the system, you should be able to add it to the Path variable in the User Environments box. I've never been on a NT system where I'm not an administrator, so I'm not positive.
A more hackish way is look at the Perl variable, $^X, although you're not guaranteed to get a path in that information. I believe you will under Windows, since argv[0] always contains a fully qualified path name, but you'd have to check that to be sure.
--Chris
e-mail jcwren | [reply] |
Same thing I told the_slycer, the PATH variable is set, but WIN32::Process::Create <bold>needs</bold> the full path to the perl.exe. I could hack $^X, but using eval would be simpler and easier to read at that point, and I'm not guaranteed it will work.
| [reply] |
You can install perl on a shared file-server, set the PATH environment on the workstations to point at the \perl\bin dir there, and make sure that everybody has the same drive mapped to the same place. This may be a little easier than installing perl on each station.
HTH | [reply] |
Perl is already installed on each workstation, but not always in the same location. The PATH environment on the workstations point to perl\bin, but when using Win32::Process::Create you need to enter the full path to the excutable, if the path is wrong the program won't run.
| [reply] |