Re: [boost] environment variable access

From: Jason Stewart (res0054p_at_[hidden])
Date: 2002-01-23 10:21:12

Dylan,

I have written  a similar set of functions for environment access and I 
wanted to make some comments. I personally like to have a get function that 
returns a string instead of taking one as a reference. I pefer to type

        string location = env::get("LOCATION");

instead of

        string location;
        env::get("LOCATION", location);

In this case you have to decide what to do if the variable doesn't exists. 
I provided a default value that gets returned in that case, i.e.

        string location = env::get("LOCATION", "c:/");

I also provided an Exists function that returns true if the variable exists 
in the environment. However, I don't often need it with the defaults.

Unfortunately, this only works well with strings, not with your other types 
but you might could have both methods.

Also, putenv is not portable (as far as I can tell). Under MSVC it is 
defined as _putenv. Since it is not portable I took the approach of using 
the native Win32 functions on Windows and posix functions elsewhere.

Windows : GetEnvironmentVariable, SetEnvironmentVariable
POSIX      : getenv, setenv, unsetenv

The setenv function does not seem to have the behavior of putenv. If I read 
the man pages correctly it makes a copy of the string instead of storing 
the exact pointer that you pass it.

I also added the ability to expand an environment variable, if it refers to 
another variable. For instance:

LOCATION = %SYSTEM%/drivers
SYSTEM     = c:/winnt

then env::get("LOCATION", "", true) would return "c:/winnt/drivers". Of 
course on non-windows platforms I used $(VARIABLE) syntax.

Someone posted on this list that platform dependencies make it less likely 
for something to be accepted by the Standards committee but it seems to me 
that the standard library is the best place to hide some of these platform 
dependencies. Take fopen, fclose, etc. Those are not implemented the same 
way for all platforms. I think that for the environment functions it might 
make sense to use native system calls as well.

Jason