-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Allow global flags after command #427
Comments
Hi @fgblomqvist, I agree with you completely. Unfortunately this is baggage that we carry from using the Go stdlib I'll leave this open as a future enhancement though! |
Okay, I see. |
The core |
@noffle mmm, that is not a bad idea given the tradeoffs. I'll try to give that a shot in the near future. Thank you for the suggestion! |
This is a hack to sidestep urfave/cli#427. Since the cli package can't handle arguments appearing *before* options, this pre-processes the os.Args and reorders them to be compatible with cli's parsing logic.
Also interested in this. |
Bump up for this one too ! |
wondering if this issue is still up for a fix :) |
Given that this is from last year, I think I'm comfortable closing it 🙂 feel free to re-open / open a new issue / comment in support if there's still interest here! |
Oh!!! I just noticed there's 22 👍s. Re-opening now 📈 |
This may have been fixed by v2? I'd appreciate if someone could investigate that 🙏 |
I loved cli library before but this issue of not able to inter-mix arguments and flags is a bit problematic. To make things worse, certain earlier version used a reordering hack (see above "hack to sidestep #427" which I kind of liked) but this change was later reverted, causing the behavior to vary greatly between versions. I understand that there are bugs regarding this both ways, but the Unix-y default should always be allowing mixing. I had to track down bugs where cli are suddenly not able to extract flag values where earlier versions worked. Switching to cobra for now. |
I don't think that this was fixed in v2, I also don't think that "local" flags are supported after the first non-flag |
Then this issue is available for anyone to work on 👍 |
This issue or PR has been automatically marked as stale because it has not had recent activity. Please add a comment bumping this if you're still interested in it's resolution! Thanks for your help, please let us know if you need anything else. |
bump |
This issue or PR has been bumped and is no longer marked as stale! Feel free to bump it again in the future, if it's still relevant. |
This issue or PR has been automatically marked as stale because it has not had recent activity. Please add a comment bumping this if you're still interested in it's resolution! Thanks for your help, please let us know if you need anything else. |
Closing this as it has become stale. |
This issue or PR has been bumped and is no longer marked as stale! Feel free to bump it again in the future, if it's still relevant. |
This is a great idea! We should definitely have this |
Okay this feature is confirmed for v3. I'd like more feedback on this. Say we define a flag for top level command
We expect both of these to behave the same. Does this work for subcmd as well i.e if a flag is defined for a cmd it should be available for subcmds as well ?
However
shouldnt work. Do we want to specifically list flags as "global" so that only those can be strewn throughout the cmdline. So for example if we define two flags f1 and f2 with f2 marked as "global"
should all work but not
|
This is just a suggestion, but to me it seems logical to allow global flags after the command as well, not only before it.
For example, if you have a verbose flag, -v:
myapp -v server
vs.
myapp server -v
To me the second one does visually make more sense. Are there cases when this is a bad idea (and therefore the reason to why this is not how it is currently implemented)?
The text was updated successfully, but these errors were encountered: