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

Allow global flags after command #427

Closed
fgblomqvist opened this issue May 23, 2016 · 22 comments · Fixed by #1568
Closed

Allow global flags after command #427

fgblomqvist opened this issue May 23, 2016 · 22 comments · Fixed by #1568
Labels
area/v3 relates to / is being considered for v3 help wanted please help if you can! kind/feature describes a code enhancement / feature request pinned should not be marked stale status/confirmed confirmed to be valid, but work has yet to start
Milestone

Comments

@fgblomqvist
Copy link

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)?

@jszwedko
Copy link
Contributor

Hi @fgblomqvist, I agree with you completely. Unfortunately this is baggage that we carry from using the Go stdlib flag library (which stops parsing the moment it hits a non-flag) so we cannot support it unless we were to rip that out and do our own flag parsing (which we have discussed a bit, but is a non-trivial effort). You can see some more conversation about this in #355.

I'll leave this open as a future enhancement though!

@jszwedko jszwedko added the kind/feature describes a code enhancement / feature request label May 24, 2016
@fgblomqvist
Copy link
Author

Okay, I see.

@hackergrrl
Copy link

hackergrrl commented Sep 14, 2016

The core flag package is BSD licensed, so perhaps the easiest fix would be to include a fork of said package, modified to support intermixed arguments/flags. This has the benefit of keeping the API identical, making the integration simpler than a rewrite or using a different 3rd-party package. Does this sound reasonable?

@jszwedko
Copy link
Contributor

@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!

hackergrrl added a commit to ipfs/ipget that referenced this issue Sep 16, 2016
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.
@0xdeafcafe
Copy link

Also interested in this.

@nikkolasg
Copy link
Contributor

Bump up for this one too !
But in the meantime, @jszwedko : Thank you so far for the good job you've done ;)

@marwan-at-work
Copy link
Contributor

wondering if this issue is still up for a fix :)

@coilysiren
Copy link
Member

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!

@coilysiren
Copy link
Member

Oh!!! I just noticed there's 22 👍s. Re-opening now 📈

@coilysiren coilysiren reopened this Aug 17, 2019
@coilysiren coilysiren added help wanted please help if you can! status/blocked requires some external dependency labels Aug 17, 2019
@coilysiren coilysiren added status/confirmed confirmed to be valid, but work has yet to start and removed status/blocked requires some external dependency labels Sep 10, 2019
@coilysiren coilysiren added the area/v2 relates to / is being considered for v2 label Nov 27, 2019
@coilysiren
Copy link
Member

This may have been fixed by v2? I'd appreciate if someone could investigate that 🙏

🔗 => https://github.com/urfave/cli/releases/tag/v2.0.0

@tanghaibao
Copy link

tanghaibao commented Dec 12, 2019

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.

@Nokel81
Copy link

Nokel81 commented Mar 5, 2020

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

@coilysiren
Copy link
Member

I don't think that this was fixed in v2

Then this issue is available for anyone to work on 👍

@stale
Copy link

stale bot commented Jun 4, 2020

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.

@stale stale bot added the status/stale stale due to the age of it's last update label Jun 4, 2020
@Nokel81
Copy link

Nokel81 commented Jun 4, 2020

bump

@stale
Copy link

stale bot commented Jun 4, 2020

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.

@stale stale bot removed the status/stale stale due to the age of it's last update label Jun 4, 2020
@stale
Copy link

stale bot commented Sep 2, 2020

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.

@stale stale bot added the status/stale stale due to the age of it's last update label Sep 2, 2020
@stale
Copy link

stale bot commented Oct 2, 2020

Closing this as it has become stale.

@stale stale bot closed this as completed Oct 2, 2020
@ghost
Copy link

ghost commented Oct 19, 2020

https://github.com/ipfs/ipget/blob/186b8ebaadd38ac340a7e07d59fa271732a8ec53/main.go#L111

@rliebz rliebz reopened this Oct 22, 2020
@stale
Copy link

stale bot commented Oct 22, 2020

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.

@stale stale bot removed the status/stale stale due to the age of it's last update label Oct 22, 2020
@rliebz rliebz added the pinned should not be marked stale label Oct 22, 2020
@coilysiren
Copy link
Member

This is a great idea! We should definitely have this

@dearchap
Copy link
Contributor

dearchap commented Oct 31, 2022

Okay this feature is confirmed for v3. I'd like more feedback on this. Say we define a flag for top level command

./app -v cmd1
./app cmd1 -v

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 ?

./app cmd1 --foo subcmd1
./app cmd1 subcmd1 --foo

However

./app --foo cmd1 subcmd1

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"

./app cmd1 subcmd1 --f2
./app cmd1 --f2 subcmd1 
./app --f2 cmd1 subcmd1

should all work but not

./app cmd1 subcmd1 --f1
./app cmd1 --f1 subcmd1 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/v3 relates to / is being considered for v3 help wanted please help if you can! kind/feature describes a code enhancement / feature request pinned should not be marked stale status/confirmed confirmed to be valid, but work has yet to start
Projects
None yet
Development

Successfully merging a pull request may close this issue.