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

#211 breaks commands that use PassAfterNonOption #275

Closed
chipaca opened this issue Sep 26, 2018 · 0 comments
Closed

#211 breaks commands that use PassAfterNonOption #275

chipaca opened this issue Sep 26, 2018 · 0 comments

Comments

@chipaca
Copy link
Contributor

chipaca commented Sep 26, 2018

With the change introduced by #211 any parser that uses commands can no longer use flags.PassAfterNonOption. I believe this is a bug, and I'll be working on a fix—please let me know if it's intended behaviour so I can leave it be (and instead change our code).

As an example, this:

package main

import (
	"github.com/jessevdk/go-flags"
)

type options struct {
	Foo struct{} `command:"foo"`
}

func main() {
	parser := flags.NewParser(&options{}, flags.PassAfterNonOption)
	if _, err := parser.Parse(); err != nil {
		println("***", err.Error())
	}
}

produces

$ go run /tmp/q.go foo
*** Unknown command `foo', did you mean `foo'?
chipaca added a commit to chipaca/go-flags that referenced this issue Sep 26, 2018
This change restores the old behaviour of PassAfterNonOption working
together with commands so that a command would (also) get everything
after the first non-option, while also preserving the new behaviour of
those non-options landing in the positional array if provided.

The behaviour for when a command and a positional array are both
present continues to be weird (but it's unclear whether there's a
non-weird way out of that one other than failing with a "don't do
that").
chipaca added a commit to chipaca/go-flags that referenced this issue Sep 27, 2018
This change restores the old behaviour of PassAfterNonOption working
together with commands so that a command would (also) get everything
after the first non-option, while also preserving the new behaviour of
those non-options landing in the positional array if provided.

The behaviour for when a command and a positional array are both
present continues to be weird (but it's unclear whether there's a
non-weird way out of that one other than failing with a "don't do
that").
jessevdk added a commit that referenced this issue Sep 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants