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