Re: [boost] Environment Variables Library?

Subject: Re: [boost] Environment Variables Library?
From: Michael Ainsworth (michael_at_[hidden])
Date: 2015-05-19 05:51:14

> On 19 May 2015, at 7:18 pm, Klaim - Joël Lamotte <mjklaim_at_[hidden]> wrote:

> 
> I'm not sure for other devs but my personal guideline so far is:
> 
> 1. Don't use the register except if you must (mostly because of
> requirements from the kind of application you are making).
> 2. Don't use environment variables except if you must (mostly for dev tools
> helping locating each other).
> 3. Prefer user-specific or shared directories to put config data in (config
> files or databases).
> 
> The reasons for the first two are mainly to avoid issues like "pollution"
> of the system with montains of unuseful data
> (in particular with computers used by non-developers).
> Part of the source of the issue is the lack of common good uninstallation
> system,
> part of it is just historical scars itching (from windows98/me era).
> 
> There is also the cross-platform code issue: if you want to provide data to
> the whole system in a cross-platform way,
> the environment variables is the only way to do so, because there is no
> register on non-windows platforms (that I know of).
> 
> The environment variables in windows have a limited size which is small
> enough to be hit very quickly if you abuse it.
> For example the famous PATH can be filled with paths to tools like
> git,hg,svn, python, ruby, your favorite C++ compilers and hit
> the point where you can't add anything anymore. Of course, this can be
> worked aroudn but it's still an annoying limitation.
> 
> Finally there is the "it's a public global state" issue, which I kind of
> like public global non-const variables in a program.
> It's just problematic.
> 
> I'm not a specialist of the windows specifics so any of my assumptions
> might be wrong.

Your comparison of environment variables in an operating system to global non-const variables in a software library is a good one - it's usage appears contrary to encapsulation principles. I can think of two generalised uses of environment variables:

1. It provides users with the ability to pass configuration information to a process, such the $CXX variable used in Makefiles, or $GIT_DIR for Git.
2. It provides processes with the ability to communicate with other processes (a rudimentary form of inter process communication), such as an HTTP server implementing the CGI specification, or SVN executing $EDITOR for commit messages.

It'd be nice for an alternative that provides a cleaner implementation with less "global namespace pollution", but regardless, it appears that in the current situation:

1. Windows does not use environmental variables as much as POSIX, but still does use them.
2. There is not great support for environmental variables in the curren C++ standard.
3. Therefore, there is a need for such a library.

Would you agree with the above from your background and experience?