Parent arguments are not handled when a sub command is defined

[b3j0f]

Hello, I already fix this issue in a dedicated PR

Describe the bug
When I define a command argument and a sub command, my argument is never handled.

To Reproduce

package main

import (
    "fmt"
    "github.com/hellflame/argparse"
)

func main() {
    parser := argparse.NewParser("basic", "this is a basic program", nil)
    name := parser.String("n", "name", nil)
    subcmd := parser.AddCommand("a", "", nil)
    if e := parser.Parse([]string{"-n", "world", "a"}); e != nil {
        fmt.Println(e.Error())
        return
    }
    fmt.Printf("hello %s\n", *t)
}

Expected behavior
Must display "hello world"

Terminal Output

hello

Environment:

• OS: MacOS 10.15
• Go Version: 1.13
• Package Version: v1.10.0

Resolution

I provided those two pull requests #19 & #20 which respectively solve my case and test the bugfix.

Regards

Additional context

[hellflame]

Thanks for the PR.
There do exist this issue when dealing with sub command, but the test case is kind of strange too.

parser := argparse.NewParser("basic", "this is a basic program", nil)
name := parser.String("n", "name", nil)
subcmd := parser.AddCommand("a", "", nil)
if e := parser.Parse([]string{"-n", "world", "a"}); e != nil {
    fmt.Println(e.Error())
    return
}

Programer defined a sub command with entry a, and will user input -n world a, this should show some notice like:

usage: xxx a [--help]

options:
  --help, -h  show this help message

and you won't get the Expected behavior
Must display "hello world"

Because this is a false use, if you want the Expected behavior, except your pr, you should add at least one argument for entry a, like:

parser := argparse.NewParser("basic", "this is a basic program", nil)
name := parser.String("n", "name", nil)
subA := parser.AddCommand("a", "", nil) // add one argument for `a`
subA.String("b", "", nil)

and the user should input -n world a -b xxx.

Frankly speaking, I didn't expect such use for a real case. In my original design, if the user choose to execute the subcommand, the main command will be shadowed, if the user want to test the sub command, just input []string{"a"}. I'm a little confused of the reason to cause this kind of use, this could be confusing for your users, would you think it twice?

[b3j0f]

Hello @hellflame and thx for the reply

My use case is a CLI for managing a server.

For example, I have this root argument -c which allows to specify a configuration file from where load server configuration.

Then, I can show the configuration with the subcommand conf, or simply execute the server with the subcommand serve, etc. (I also other subcommands list listusers, setadmins, etc., where the -c is useful, but I think those two use cases might explain my issue)

I thought to use the -c for every subcommands with the magy of copy/paste :-/

Maybe a parent argument might be duplicated to subcommands ?

[b3j0f]

Oh, I just discovered the argument property "Inherited". Maybe it is sufficient for my case... I test it and I give you a feedback

[b3j0f]

Ok, it works perfectly.

Your library is really my favorite, thanks for your work !

[hellflame]

Thanks for using this library. We can build it better and better.