Does setenv not set variables for MEX functions?

Hello,

I have noticed that when I use setenv in MATLAB on Windows, the change is not visible in MEX functions. The behavior is as I would expect on Linux. I tested the following MEX function on MATLAB 2011a and 2012a:

#include <mex.h>
void mexFunction(int nargout, mxArray *pargout [ ], int nargin, const mxArray *pargin[])
{
  printf("OS  %s\n", getenv("OS"));
  printf("AAA %s\n", getenv("AAA"));
}

When I run test from MATLAB comandline I get

    >> test
    OS  Windows_NT
    AAA (null)

I get exactly the same when I setenv('AAA') to some value:

>> setenv('AAA','BBB')
>> getenv('AAA')

ans =

BBB

>> test
OS  Windows_NT
AAA (null)

Is that a feature, or is it a bug?

Thanks a lot!

Marcin

Answer 1

[Friedrich]

Hi,

I think the following Microsoft statement should help here:

"getenv and _putenv use the copy of the environment pointed to by the global variable _environ to access the environment. getenv operates only on the data structures accessible to the run-time library and not on the environment "segment" created for the process by the operating system. "

http://msdn.microsoft.com/en-us/library/tehxacec(v=vs.80).aspx

I think you would need to use GetEnvironmentVariable instead

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683188%28v=vs.85%29.aspx

To answer it pretty short: It seems like getenv only looks at the global variables, and GetEnvironmentVariable works for application specific too

I modified the code to (change extension to .cpp)

#include <mex.h>
#include "Windows.h"

void mexFunction(int nargout, mxArray *pargout [ ], int nargin, const mxArray *pargin[])
{
    const DWORD buff_size = 50;
    LPTSTR buff = new TCHAR[buff_size];
    DWORD var_size;
    buff[0] = '\0';
    printf("OS  %s\n", getenv("OS"));
    printf("AAA %s\n", getenv("AAA"));
    var_size = GetEnvironmentVariable("AAA",buff,buff_size);
    printf("AAA through GetEnvironmentVariable %s\n",buff);
}

And when you run it you see this:

>> test
OS  Windows_NT
AAA (null)
AAA through GetEnvironmentVariable 
>> setenv('AAA','BBB11')
>> test
OS  Windows_NT
AAA (null)
AAA through GetEnvironmentVariable BBB11
>>

[Kaustubha Govind]

Nice! Great answer Friedrich. :)

Answer 2

[Kaustubha Govind]

I think this is an OS-defined behavior and not specific to MATLAB. Extrapolating from this discussion, the loader (which is what calls into the MEX-file - since MEX-files are essentially DLLs/shared libraries) reads the environment variables at the time of MATLAB startup, and does not notice your changes to the environment variables, which in turn means that the MEX-file doesn't see them.

[Walter Roberson]

I believe that discussion only applies to the LD_LIBRARY_PATH, as a security measure in the OS being discussed (OS-X).

The setenv() behavior that Marcin is seeing on Linux is what I would expect on any POSIX-compliant system. (Hmmm -- I really ought to buy an electronic copy of the POSIX.1 standards!)

Windows XP SP2 and later are supposedly POSIX compliant (but I have my personal doubts about the completeness of that compliance.)

[angainor]

I agree with Walter, this is also what I would also expect.

I need to set env. variables to dynamically change beetween OpenMP configuration of parallelized MEX functions. Setting OMP_NUM_THREADS once before MATLAB execution is not a good option - optimal thread setting depend on the problem at hand, problem size etc. It works perfectly on linux and I can decide on how many cores every individual MEX function runs.

Note this discussion and an answer of Dan Hensley: "Another trick I routinely use is to set the PATH in Matlab using getenv and setenv prior to calling the Mex file. This works on Windows, but not Linux.". He seems to have the same problem, but for him it works on Windows.

[Kaustubha Govind]

Do you think that there might be a difference on the Windows OS version? Perhaps Dan was not using Windows NT?

[Walter Roberson]

"Windows NT" is what shows up as the OS for anything derived from Windows NT, including XP, Vista, and Windows 7.

[Kaustubha Govind]

Ah! Okay then. I'm still inclined to think that this might be OS-defined behavior, but I don't have much experience with this, so I would recommend contacting MathWorks Tech Support at this point. Sorry!

[angainor]

Thank you! I guess I'll do that..