Hi,
On Windows 2000, perl 5.8.6, I have an Inline::C script that accesses the
ghostscript dll. For the program to succeed, I need to set the environment
variable:
GS_LIB=F:\gs\gs8.51\lib;F:\gs\fonts
All works well if I set that environment variable at the command prompt, by
entering:
D:\ghostscript>set GS_LIB=F:\gs\gs8.51\lib;F:\gs\fonts
But if, instead of doing it that way, I try to do it in the perl script:
$ENV{GS_LIB} = 'F:\gs\gs8.51\lib;F:\gs\fonts';
then it doesn't find the files that it needs to find (which are located in
the specified directories). The variable is set correctly - I can see that
by running the following command in the same perl script:
system("set");
That shows quite clearly that GS_LIB has been set to the correct value - but
for some reason the environment variable is not visible when it needs to be.
So .... I thought ... well, maybe the environment variable needs to be set
within the Inline::C function that I'm calling (there's only *one* inline
function btw). So, in that Inline::C function I placed:
if(_putenv("GS_LIB=F:\\gs\\gs8.51\\lib;F:\\gs\\fonts") != 0)
croak("Failed to set GS_LIB environment variable");
I guess that's the right way to do it - I get unrecognised escapes if I use
single backslashes, and forward slashes don't work. Again that doesn't help.
I can set the environment variable in *both* the perl script and the
Inline::C function, and it's still not visible when it needs to be.
Btw, the _putenv() call succeeds (ie returns 0).
The *only* way I can get the program to run successfully is to set the
environment variable by entering it at the command prompt.
Any thoughts on why this is so, and how to successfully set the environment
variable from within the script ?
Possibly not relevant - but I also have a Win32::API version of the same
script that accesses the ghostscript dll directly. In it I *can* set the
environment variable successfully from within the script by doing:
$ENV{GS_LIB} = 'F:\gs\gs8.51\lib;F:\gs\fonts';
Cheers,
Rob
