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