Re: environment variable access

From: mfdylan (dylan_at_[hidden])
Date: 2002-01-23 17:28:31

--- In boost_at_y..., Jason Stewart <res0054p_at_g...> wrote:
> Dylan,
> 
> 	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.

I think that might be the best option actually (having both).  The 
default parameter might be worth adding.
 
> 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

Nope, putenv is POSIX, and _should_ work the same everywhere (ie the 
string is placed as is into the environment, so that further 
modifications to the same string modify the environment directly).
Neither setenv and unsetenv are POSIX, although now you mention it 
having an explicit "unset" function (as opposed to calling set with 
an empty string) is probably a good idea).  The problem with using 
SetEnviromentVariable directly is that future calls to getenv() won't 
pick it up, and the getenv() may be in a library you have no control 
over.  putenv/getenv under VC (you don't need the underscore btw) 
both update the CRT environment and the "OS" environment.  I don't 
know how well putenv/getenv are supported by other Windows compilers 
(or for macintosh - VC's putenv source is commented out for Mac).

> 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.
> 
Actually variable expansion needs to be offered "standalone" as it 
were - you should be able to expand any string, regardless of whether 
it comes from the environment or not.  It's probably worth having it 
support both %...% and $ (parentheses optional) according to certain 
flags (that would default to %...% under Win32 and $ elsewhere).

> 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.
> 
I agree totally.  The problem is that the C++ standards committee 
want to keep C++ suitable for an operating system with as few 
requirements as possible - assuming the existence of environment 
variables would add an extra requirement.  But this isn't really 
fair, just because an OS doesn't have native support for environment 
variables doens't mean you can't implement 'env' with sensible 
behaviour.
Anyway I think boost is a good place for things that rely on OS-
support that the C++ isn't happy about assuming exists (for instance 
the dir_it stuff really needs to be finalised.  C++ itself doesn't 
assume OS's even have directories).  All POSIX functionality, in 
particular, I think needs to be wrapped up in a recognised C++ 
library.  I've been doing this a bit recently (so far I've done 
glob, dlopen/sym/close and getenv/putenv.  exec() is probably the 
next one on my list, although hiding the difference between fork+exec
() and CreateProcess is going to be the main challenge!).

Dylan