v2 feature: allow flags after arguments

[jhford]

Checklist

• Are you running the latest v2 release? The list of releases is here.
• Did you check the manual for your release? The v2 manual is here
• Did you perform a search about this feature? Here's the Github guide about searching.

What problem does this solve?

I am writing a program which is invoked by another program (openvpn up-script) and it is invoked in a very specific way. I really like this library, so I'd like to be able to use it as a command line parser. The problem is that it seems that all flags must appear before all options.

In my specific case, openvpn will always call your script with exactly 10 arguments, then you can configure it to pass additional arguments. This would result in an os.Args similar to this:
{"tun0", "1", "2"..."10", "--flush"}. The --flush is the flag that I'd like to be able to process with this library.

It seems like all flags either take no arguments (BoolFlag) or take one arugment (StringFlag).

I've needed this for other projects, but having it for this project would be really great.

Solution description

an os.Args value of {"a", "--bool-flag", "--string-flag", "abc", "b"} should have:

• ctx.Args() --> {"a", "b"}
• ctx.BoolFlag("bool-flag") --> true
• ctx.StringFlag("string-flag") --> "abc"

Describe alternatives you've considered

Not using this library for some of my projects

[AudriusButkevicius]

Habe you tried setting the flags on the root of the app rather than the command itself?

[AudriusButkevicius]

See #585

[kor44]

A lot of CLI tools supports flags after arguments. Today switch one of my application to this package and fount this feature is not supported.

[msmans]

@AudriusButkevicius #585 isn't the same as this issue. v2 still doesn't allow for flags after positional arguments.

[belgaied2]

This is still a problem, @AudriusButkevicius is it possible to re-open this issue?

[punmechanic]

@AudriusButkevicius ran into this today with v2 and v3 and noted that v1 had the desired behavior. Is there an appetite to re-open this?

We're looking to migrate an existing CLI off of cobra and to urfave/cli as this library is simpler, but it would be a breaking change to have to require all of our users to start placing their flags before the args, so we're unable to if this issue is not resolved.

It doesn't make sense for us to have command-specific flags placed on the root application and thus available to the entire application to achieve this behavior.

[amalshaji]

Any updates on this issue? Will this be fixed in v3?

[dearchap]

We are still waiting on a flag parser replacement for this.

[BlueTree242]

I hope this is fixed soon

[dearchap]

Highly unlikely . We've decided to keep the current parser as it is . V3 had support for persistent flags which allows flags to be placed anywhere in the command chain (but not after args)

[BlueTree242]

Well I am using V3, even though it isn't documented, will this ever be added? It's such a basic thing and the user will most likely be confused why the flags aren't doing anything

[guiguan]

ya, please support flags anywhere

[fiatjaf]

I've opened an official feature request for this for v3, which is the only way maintainers will consider fixing it. Please upvote it if you still want it: #1950

There is also a branch and a PR that kinda works linked there that I'm using myself.