Accessing Environment Variables In C++
C++Environment VariablesC++ Problem Overview
I'd like to have access to the $HOME
environment variable in a C++ program that I'm writing. If I were writing code in C, I'd just use the getenv()
function, but I was wondering if there was a better way to do it. Here's the code that I have so far:
std::string get_env_var( std::string const & key ) {
char * val;
val = getenv( key.c_str() );
std::string retval = "";
if (val != NULL) {
retval = val;
}
return retval;
}
Should I use getenv()
to access environment variables in C++? Are there any problems that I'm likely to run into that I can avoid with a little bit of knowledge?
C++ Solutions
Solution 1 - C++
There is nothing wrong with using getenv()
in C++. It is defined by stdlib.h
, or if you prefer the standard library implementation, you can include cstdlib
and access the function via the std::
namespace (i.e., std::getenv()
). Absolutely nothing wrong with this. In fact, if you are concerned about portability, either of these two versions is preferred.
If you are not concerned about portability and you are using managed C++, you can use the .NET equivalent - System::Environment::GetEnvironmentVariable()
. If you want the non-.NET equivalent for Windows, you can simply use the GetEnvironmentVariable()
Win32 function.
Solution 2 - C++
I would just refactor the code a little bit:
std::string getEnvVar( std::string const & key ) const
{
char * val = getenv( key.c_str() );
return val == NULL ? std::string("") : std::string(val);
}
Solution 3 - C++
- If you are on Windows you can use the Win32 API GetEnvironmentVariable
- On other linux/unix based systems use getenv
Why use GetEnvironmentVariable in Windows, from MSDN getenv:
> 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. Therefore, > programs that use the envp argument to > main or wmain may retrieve invalid > information.
> This function can retrieve either a > system environment variable or a user > environment variable.
Solution 4 - C++
In c++ you have to use std::getenv and #include <cstdlib>
Solution 5 - C++
A version of @Vlad's answer with some error checking and which distinguishes empty from missing values:
inline std::string get_env(const char* key) {
if (key == nullptr) {
throw std::invalid_argument("Null pointer passed as environment variable name");
}
if (*key == '\0') {
throw std::invalid_argument("Value requested for the empty-name environment variable");
}
const char* ev_val = getenv(key);
if (ev_val == nullptr) {
throw std::runtime_error("Environment variable not defined");
}
return std::string(ev_val);
}
Notes:
-
You could also replace the use of exceptions in the above with an
std::optional<std::string>
or, in the future, with anstd::expected
(if that ends up being standardized). -
I've chosen safety over informativity here, by not concatenating the key into the what-string of the exception. If you make the alternative choice, try and limit copying from
key
to within reason (e.g. 100 characters? 200 characters?), and I'd also check these characters are printable, and sanitize those characters.
Solution 6 - C++
Yes, I know this is an old thread!
Still, common mistakes are, by definition, not new. :-)
The only reasons I see for not just using std::getenv(), would be to add a known default or to adopt common pattern/API in a framework. I would also avoid exceptions in this case (not generally though) simply because a non-value return is often enough a valid response for an environment variable. Adding the complexity of handling exceptions is counter-intuitive.
This is basically what I use:
const char* GetEnv( const char* tag, const char* def=nullptr ) noexcept {
const char* ret = std::getenv(tag);
return ret ? ret : def;
}
int main() {
int ret=0;
if( GetEnv("DEBUG_LOG") ) {
// Setup debug-logging
} else {
...
}
return (-1==ret?errno:0);
}
The difference between this and the other answers may seem small, but I find such small details are very rewarding when you form habits in how you code.
Just like the fact that getenv() returns a non-const pointer, which could easily lead to bad habits!