Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unknown option gives user unfriendly error #24

Open
solid-angle opened this issue May 21, 2020 · 5 comments
Open

Unknown option gives user unfriendly error #24

solid-angle opened this issue May 21, 2020 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@solid-angle
Copy link

solid-angle commented May 21, 2020

If you misspell or provide an option that doesn't have a parser, when at least one argument is present in the parser, the returned error code isn't very user friendly.

Easiest to show with an example.

Given this code

#include <lyra/lyra.hpp>
#include <filesystem>
#include <iostream>

int main(int argc, char** argv)
{
    bool showHelp=false;
    bool verbose = false;
    auto cli = lyra::cli_parser();

    cli.add_argument(lyra::help(showHelp));
    cli.add_argument(lyra::opt(verbose)
        .name("--verbose").help("Verbose logging").optional());

    std::filesystem::path projectDirectory;
    cli.add_argument(lyra::arg(projectDirectory, "ProjectDirectory")
        .required().help("Project directory"));

    auto result = cli.parse({ argc, argv });

    if (!result)
    {
        std::cerr << result.errorMessage() << std::endl;
        return 1;
    }

    std::cout << projectDirectory.string() << std::endl;
    return 0;
}

and the commandline arguments

--foo /my/project/directory

The returned error is

Unrecognized token: /my/project/directory

Expected: Parser should recognize the '--' or '-' prefix on '--foo' and give an error about the missing option.

@grafikrobot grafikrobot added the bug Something isn't working label May 21, 2020
@grafikrobot
Copy link
Member

After some investigation... This is technically not a bug. The current behavior is that it interprets the --foo as the value for the ProjectDirectory argument after having it not match the know options. Subsequently it sees the /my/project/directory and can't match it to anything, as it's not a known option, and it already parsed the one argument. Hence fails the parse at that point. And complains about it.

I'll have to think about it more to see if there's a way to deal with this use case.

@grafikrobot grafikrobot added enhancement New feature or request and removed bug Something isn't working labels May 23, 2020
@vadz
Copy link

vadz commented Apr 9, 2021

It might well be not a bug technically, but this behaviour is very surprising and unwelcome. In practice this happens when the user makes a typo in the option name, e.g. suppose your program synopsis is a.out [--overwrite] <file>.... Running it as ./a.out --overrite file really ought to give an error about an unknown option rather than creating an output file called --overrite!

(and, of course, if you really wanted to create a file called like this, you should be able to use ./a.out -- --overrite file)

@grafikrobot
Copy link
Member

@vadz indeed, it's annoying. Which is why I haven't closed this :-) Addressing this is not easy because it break backwards compat. But I'm thinking that okay in this case. Just will take more thinking to minimize the impact.

@vadz
Copy link

vadz commented Sep 1, 2021

Would you be interested in a PR implementing this? I'd like to finally do something about it, because as much as I like Lyra's API, we can't tell our users never to make typos in their command lines (spoiler: it doesn't work).

@grafikrobot
Copy link
Member

@vadz if you can think of a way to do it I'd love to have a fix for it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: 🆕 New
Development

No branches or pull requests

3 participants