[Boost-users] boost::program options - why not allow_unregistered() for environmental variable parser?

Subject: [Boost-users] boost::program options - why not allow_unregistered() for environmental variable parser?
From: Ivan Godard (igodard_at_[hidden])
Date: 2008-10-15 13:03:26

    Vladimir Prus wrote:

>     > The environment seems to be the one place that is guaranteed to have
>     > unregistered options, because it is full of things (like
>     > $LD_LIBRARY_PATH) of no interest to the program doing the parsing. A
>     > call on parse_environment always throws on these. As far as I can see in
>     > the code, the way to avoid the throw is to pass parse_enviroment a
>     > function that checks for each of the options that are actually wanted
>     > and returns the null string for the rest. Of course, this duplicates
>     > what the parser just did.
>     > 
>     > Is there a better way?
>         

    The recommended way is to use some name prefix for environment variables
    affecting your program -- say MY_PROG_. Then, pass this prefix to
    parse_environement and all variables without that prefix will be ignored.

    Does this help?

    - Volodya
      

Unfortunately no. My code must interact with a large third-party 
application with a ton of environmental variables that follow no 
particular naming convention, and I wanted to integrate the probe for 
those variables with my own command line so I could accept the 
environment as default but overwrite them from the command line using 
the same names (which are already documented by the third party and 
mostly familiar to the users). Having no accept_unregistered precludes 
that approach, and I have to use getenv() and do it by hand instead. 
It's not a hard workaround, just a day or two of work, but lacking 
accept_unregistered for only one of the three kinds of parser seems odd 
given the general elegance of the rest of your library.

Ivan