Skip to content
New issue

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

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

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants