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

Position-independent options #64

Open
schmich opened this issue Dec 1, 2017 · 4 comments
Open

Position-independent options #64

schmich opened this issue Dec 1, 2017 · 4 comments

Comments

@schmich
Copy link

schmich commented Dec 1, 2017

From what I can tell, there is no way to have a single-declaration global option that applies across all subcommands (i.e. its position on the command-line doesn't matter).

For example, let's say I have a command-line program foo which has subcommand bar which has subcommand baz. I can invoke this as foo bar baz.

Now, let's say I wanted to add a verbose logging flag -v which applies regardless of command/subcommand. Ideally, then, the following would be equivalent (I could specify the flag anywhere on the command-line):

  • foo -v bar baz
  • foo bar -v baz
  • foo bar baz -v

I'd like to do this without having to define a BoolOpt on foo, bar, and baz. Is there currently a way to do this by just defining a single global BoolOpt?

In my actual use case, I have four levels of commands (i.e. foo bar baz quux --opt waldo). I would like to be able to specify verbosity (-v, -vv, -vvv) as well as remote connection strings (--connection tcp://192.168.1.100:9000) without needing to worry about their position.

Thanks for your work on this library. It's a boon for the community, and I find myself reaching for it often.

@jawher
Copy link
Owner

jawher commented Dec 1, 2017

@schmich Thank you for your kind words and for raising this issue.

It's been a while now that I have been thinking about this idea, ie. something similar to Cobra's persistent flags.

I'm accepting this feature request as I agree it's a "very nice to have".
No promises though on when this would be implemented: I've been very bad a keeping them in the past 😆

@schmich
Copy link
Author

schmich commented Dec 2, 2017

I appreciate the consideration, and I totally understand the "no promises" aspect.

@mozillazg
Copy link

@jawher Is there any news about this feature?

@jawher
Copy link
Owner

jawher commented Jan 18, 2018

@mozillazg sorry, but I haven't been able to look at this yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants