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

Options without arguments are lost #431

Closed
jnm2 opened this issue Mar 4, 2019 · 6 comments

Comments

Projects
None yet
2 participants
@jnm2
Copy link

commented Mar 4, 2019

There doesn't appear to be a way to find out whether an option was specified unless you also add an argument. This program prints false whether or not --no-start is specified:

public sealed class Program
{
    public static Task<int> Main(string[] args)
    {
        var root = new RootCommand(handler: CommandHandler.Create((bool noStart) => Console.WriteLine(noStart)))
        {
            new Option("--no-start", "Explanation")
        };

        return root.InvokeAsync(args);
    }
}

This causes it to start working, but it also causes the help screen to show --no-start <NOSTART> instead of leaving it at the more desirable --no-start.

            new Option("--no-start", "Explanation", new Argument<bool>(defaultValue: false))
Usage:
  TestApp [options]

Options:
  --no-start <NO-START>    Explanation
  --version                Display version information

I don't know when I would ever want to see <NO-START>. If anything shows up for a flag option, it should be square brackets to indicate that flags don't require a value: --no-start [ true | false ].

But before we get that far, it really seems like the first program should work.

(Using 0.1.0-alpha-63902-01)

@jonsequitur jonsequitur added the bug label Mar 4, 2019

@jonsequitur

This comment has been minimized.

Copy link
Collaborator

commented Mar 4, 2019

The first issue looks like a binding bug.

We should also make the help output clearer for bool arguments, although in your initial code example, there's no clear way to infer the type of the argument.

@jnm2

This comment has been minimized.

Copy link
Author

commented Mar 4, 2019

I was thinking that the fact that there is no argument could be used to infer that the option is a flag. If that's wrong, what does it mean to leave the argument null? That it will default to what the binder finds?

@jonsequitur

This comment has been minimized.

Copy link
Collaborator

commented Mar 4, 2019

System.CommandLine has both early binding and late binding behaviors, so it's possible to define an Option without specifying an Argument.ArgumentType. In this case, the binding to a type depends on what you ask it for.

The following code illustrates this behavior (which is working) and shows that the bug is in binding to a method parameter.

bool? received = null;

var root = new RootCommand(handler: CommandHandler.Create((bool noStart) => received = noStart))
            {
                new Option("--no-start", "Explanation"
                            // , argument: new Argument<bool>() // <-- Both assertions pass if you uncomment this
                    )
            };

var result = root.Parse("--no-start").ValueForOption<bool>("--no-start"); 

result.Should().BeTrue(); // <-- Passes

await root.InvokeAsync("--no-start ");

received.Should().Be(true); // <-- Fails (bug)
@jnm2

This comment has been minimized.

Copy link
Author

commented Mar 4, 2019

I see. So passing null as the argument doesn't mean "this option will not be syntactically followed by an argument," i.e. the option is a simple flag, but rather "the argument will be late-bound." I wonder if this could be documented easily.

@jonsequitur

This comment has been minimized.

Copy link
Collaborator

commented Mar 13, 2019

@NextTurn That would be more expressive, but it's not supported since Argument.None isn't evaluated at compile time.

@jonsequitur

This comment has been minimized.

Copy link
Collaborator

commented Mar 13, 2019

So passing null as the argument doesn't mean "this option will not be syntactically followed by an argument," i.e. the option is a simple flag, but rather "the argument will be late-bound."

Correct. There are two different concepts in play here:

  • Argument.Arity, which is the number of tokens that will be associated with an option or command at parse time, and
  • Argument.ArgumentType, which is the .NET type that the argument is intended to be bound to.

By default, Arity is inferred based on ArgumentType, but they're allowed to differ to support custom binding.

We definitely need to make the API clearer here.

jonsequitur added a commit that referenced this issue May 4, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.