Problem of parsing with additional optional arguments

[najibprog]

Context

Hi, I'm using CLI11 in my project, and it's a very nice alternative to the Boost parser!

This is my variable parser:

CLI::App _cmdLineOptionsCLI;

I'm using the function _cmdLineOptionsCLI.parse(argc, argv) by giving a vector of options.
It may be that the options in argv are not in the options defined by add_options, so I added a

cmdLineOptionsCLI.allow_extras(true);

The problem

When I have for example "--nbVar ; 5" in my argv and are not defined in add_options, "--nbVar" is considered by the classifier like a Classifier::LONG and "5" is considered like a Classifier::NONE, so with the first arguments, we pop correctly the option, but with 5 we reach this line of code

posOpt = opt.get(); in CLI11_INLINE bool App::_parse_positional

By reaching this line, it fills a variable containing options defined by add_options, which is incorrect.

A solution proposed

If we add some lines to pop_back the argument and the value if the classifier is SHORT, LONG, WINDOWS_STYLE, it solves the problem. We suppose that if we have extra args like this "--nbVar 5", we can remove two elements instead of only one.
Is it possible to add these lines of code like this?

        if(current_type == detail::Classifier::LONG || current_type == detail::Classifier::WINDOWS_STYLE ||
           current_type == detail::Classifier::SHORT ) {
                args.pop_back();
        }

App_inl.hpp line 2005.

Best regards,
Najib

[phlptp]

One way we have gotten around this issue before is by using validate_positionals() on the app. This ensures that each assigned positional matches what is expected. Doesn't fix all cases but does in many.

The problem with the above approach is that options can have variable numbers of arguments (0,1, 2, etc). 0 and 1 are most common and assumptions about how many there are would break quite a bit of code, so ends up worse than the situation you described. The only other option would be to develop the logic for a 2 pass parsing in which some unrecognized options are delayed in parsing until the second pass to fill up positionals.

My recommendation would be to check if validate_positionals would work in your case, which works particularly nicely if the positionals define file paths or something of that sort.

[najibprog]

Thank you for your reply ! I have tested using validate_positionals, but I have the same problem. In my case, I think that I will integrate CLI11 inside my project by making this modification and informing the users to use extra arg with type (--, -, /) by having only one element after the option.

Best regards
Najib