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

argparse help shows arguments in the wrong order #7934

Closed
rlipscombe opened this issue Dec 5, 2023 · 4 comments · Fixed by #7945
Closed

argparse help shows arguments in the wrong order #7934

rlipscombe opened this issue Dec 5, 2023 · 4 comments · Fixed by #7945
Labels
bug Issue is reported as a bug help wanted Issue not worked on by OTP; help wanted from the community team:VM Assigned to OTP team VM

Comments

@rlipscombe
Copy link
Contributor

Describe the bug
In experimenting with argparse -- https://www.erlang.org/doc/man/argparse.html, it seems that the help text displays positional arguments for nested commands in the wrong order.

To Reproduce

main(Args) ->
    argparse:run(
        Args,
        #{
            arguments => [#{name => global}],
            commands => #{
                "list" => #{
                    arguments => [#{name => what}],
                    handler => fun(A) -> io:format("~p~n", [A]) end
                }
            }
        },
        #{progname => ?MODULE}
    ).

Here we have an example that takes a "list" command, taking two arguments: "global" (common to all commands) and "what" (specific to the "list" command).

The help text shows the following:

% ./example list
error: example list: required argument missing: global
Usage:
  example list <what> <global>

Arguments:
  what   what
  global global

You can see that it claims to expect "what" and then "global".

However, the parser expects "global" and then "what" as seen here:

./example list global what
#{global => "global",what => "what"}

Expected behavior

The help text should display the positional arguments in the correct order.

Affected versions

OTP-26.1.2

Additional context

I guess you could argue that it's kinda weird to use positional arguments in the face of sub-commands, but argparse allows it, so it should do it correctly.

@rlipscombe rlipscombe added the bug Issue is reported as a bug label Dec 5, 2023
@IngelaAndin IngelaAndin added the team:VM Assigned to OTP team VM label Dec 11, 2023
@jhogberg jhogberg added the help wanted Issue not worked on by OTP; help wanted from the community label Dec 11, 2023
@jhogberg
Copy link
Contributor

Thanks for your report! We're a bit swamped at the moment so we're not going to be able to fix this in the near future, a PR would be much appreciated.

@rlipscombe
Copy link
Contributor Author

While investigating, I came up with another repro:

1> io:put_chars(argparse:help(#{arguments => [#{name => first}, #{name => second}], commands => #{"cmd" => #{arguments => [#{name => third}, #{name => fourth}]}}}, #{progname => example, command => ["cmd"]})).
Usage:
  example cmd <third> <fourth> <first> <second>

Arguments:
  third  third
  fourth fourth
  first  first
  second second
ok

This shows that each group of arguments is in the correct order, but the groups are reversed.

@max-au
Copy link
Contributor

max-au commented Dec 11, 2023

Thanks for reporting, taking a look at it.

rlipscombe added a commit to rlipscombe/otp that referenced this issue Dec 11, 2023
rlipscombe added a commit to rlipscombe/otp that referenced this issue Dec 11, 2023
@rlipscombe
Copy link
Contributor Author

And to be explicit about the expected order of the arguments when run:

1> argparse:run(["cmd", "1", "2", "3", "4"], #{arguments => [#{name => first}, #{name => second}], commands => #{"cmd" => #{handler => {maps, to_list}, arguments => [#{name => third}, #{name => fourth}]}}}, #{progname => example}).
[{first,"1"},{second,"2"},{third,"3"},{fourth,"4"}]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue is reported as a bug help wanted Issue not worked on by OTP; help wanted from the community team:VM Assigned to OTP team VM
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants