Add support for specifying only a shortflag

[cornfeedhobo]

This PR seeks to add support for specifying flags with only a shortflag.

$ go test -race -cover
PASS
coverage: 63.9% of statements
ok      github.com/spf13/pflag  1.040s

Fixes #139
Closes #165
Closes #171
Fixes spf13/cobra#679

[jharshman]

@cornfeedhobo yes I like this approach. 👍

[mckern]

Not my project (so not my call to make), but I think that mixing "only short flag" and "short or long flags" is an inconsistent approach to UX; doubly so since the convention around short flags is that any values passed to them are space delimited and and long flags can be space or = delimited.

I know some projects do it (certbot comes to mind) but I don't think I've ever seen a situation where a ton of mixed-format flags was more useful than a reasonable config file or the ability to pass in serialized data (e.g. using a structured JSON document to pass data to the aws cli instead of defining each parameter as an individual flag).

[cornfeedhobo]

For anyone following this. I'm still working on it, but haven't had time to write all the tests I want.

[cornfeedhobo]

@jharshman I started adding tests but that is becoming sprawling. I'm submitting this in it's current state. Let me know what you think.

[rsteube]

Just tried this out, looks pretty good to me.

[cornfeedhobo]

@rsteube thanks. You can check out my fork where I'm starting to merge down some more of these PRs.

[cornfeedhobo]

This has been merged into my fork. Closing now.

[franck-li]

why does this feature which support shorthand only flags not work now. How to use this feature?

[rsteube]

it is not merged into spf13/pflag. You need to use his fork if that is an option for you:

go mod edit -replace github.com/spf13/pflag=github.com/cornfeedhobo/pflag
``

[major0]

I have read some of threads/PR's regarding short-only flags, and I have to say, I am fundamentally disappointed in how this feature has progressed; or failed to progress in the end.

The lack of response and gaslighting that happened against the original contributor is fundamentally shocking:

• Insanely long periods of silence and then telling people to be patient.
• Claiming an issue opened in Cobra to discuss Cobra's reliance on spf13/pflag, in part due to the short-flag issue, was somehow the wrong location for such a discussion? The claim that it was the "wrong location" was made in a discussion for a PR in a in a completely different project and not in the original discussion.
• Subsequently locking issues w/out explanation. Even if the issue was the wrong location for the topic, IMHO, a message should have been included in the original issue directing future conversations, possibly to a new issue. Paper/Audit trails are a GoodThing(tm).
• Completely ignoring requests for feedback.

At the end of the day, short-only and long-only flags are not only common place, but in many applications they are required; particularly GNU and POSIX applications. Anyone arguing against short-only options are explicitly dictating the development direction of other projects as well as basically telling anyone that needs short-only options to go-somewhere-else.

I have such a project, and at this point, I will be going somewhere else.

PS: I would like to have added this comment to the related Cobra discussion, but that discussion was locked, even though I very much feel it shouldn't have been.

Refs:

• Support for short flag only? cobra#679
• Discuss the reliance on spf13/pflag cobra#1050
• Add support for specifying only a shortflag #171
• Add support for specifying only a shortflag #256

[jharshman]

@major0 , unfortunately I haven't been active on this project for some time due to conflicting priorities. I don't remember locking that conversation but I agree that it shouldn't have been. I'll leave it to active maintainers to unlock that discussion as I don't want to step on anyone's toes.

I reviewed the PRs and conversations and I do wish I had more time to dedicate to this back then. I think short-only flags are a perfectly reasonable feature to have and I regret any mishandling of the subject.

[major0]

What I currently find the most ironic about this is that, in the README.md is the claim:

pflag is a drop-in replacement for Go's flag package, implementing POSIX/GNU-style --flags.

pflag is compatible with the GNU extensions to the POSIX recommendations for command-line options.

Anything which supports POSIX getopt() and GNU's getopt_long(), or is trying to emulate that behavior, should be able to handle:

• long-options: --long-opt[[=| ]<value>]
• short-options: -o [<value>]
• long-only options
• short-only options: @Nuru seemed to have an opinion which differed with industry standard practices and POSIX/GNU standards.
• option compaction: -abc123 [<param>]. E.g. tar -xavf <file>
• position independence: processing the args list and moving non-flags to the end of the list until no more flags exist and the remainder of the arg list is positional parameters. Processing should be aborted should -- be encountered in the args and the remaining args list handed off unmodified.

_ Note: With some fairly minor processing, it is also possible to pause processing the args list when encountering a subcmd, process subcmd flags, and then return to processing parentCmd flags. But I totally understand how no one wants to support subcmd's overriding global flags, even if it seems sort of lazy when one encounters a system that doesn't allow it._

Now, I have a pretty common POSIX/GNU scenario that requires a many-to-one mapping of multiple short-flags to a single long-flag. This behavior is common in CLI's which support options such as --format=<format1|format2|format3> [-1] [-2] [-3].

E.g. --format=<json|yaml|xml|text> [-j] [-y] [-x] [-t]

Or we can pull from a real POSIX/GNU tool, ls , which supports:

ls --format=<across|commas|horizontal|long|single-column|verbose|vertical>

And the format can also be selected via:

• -x = --format=across
• -m = --format=commas
• -x = --format=horizontal
• -l = --format=long
• -1 = --format=single-column
• -l = --format=verbose
• -C = --format=vertical

This is typically implemented by either:

---

1. Supporting a dest variable as well as a value to place into said dest whenever the flag is encountered.

Something like:

// example from how I would like to see this in Cobra
cmd.Flags().DestVarP(&format, "", "x", "across", "list entries by lines instead of columns")

Where we can disable long options by passing "" and specify the value, across, to place in the target variable, format.

Also, this should not support -x=across, this usage pattern is non-intuitive and not part of POSIX or GNU behavior.

---

2. specify a function to be run every time a flag is encountered such that we can do our own thing. This would still require support for short-only and long-only options.

---

Similar requirements arise with ls -A vs ls -a or ls -AaAaAaAa where -a and -A change the always variable between one of 3 values: Never, Always, AlmostAlways.

In the scope of POSIX/GNU commands, a "toggled" command needs to support knowing what the last flag that was used to toggle the variable was. This is important for tooling such as less, ls, grep, etc, which can pull their Options from the Environ and still allow subsequent selections by the user.

Honestly, w/out the above functionality, I would suggest removing any claim about spf13/pflag as being POSIX/GNU. Simply supporting long-opts and short-opts does not POSIX/GNU one make. It is a little like claiming all vehicles with 4 wheels that are painted red and have a gasoline engine can claim to be "Porsche Like"...

[jharshman]

I'm sure there are differing opinions on this topic but I think the first implementation example you gave makes a lot of sense to me.

[tomasaschan]

I just came on here as a co-maintainer to help unblock things late last year; most of the referred background is completely unknown to me (and, to be frank, does not appear from your description to have been constructive enough that it's worth digging deeply into...).

Is there something we co-maintainers can do today to try to rectify this? Are there any PRs or issues you would like to see (re-)considered? (This one?) If a PR is re-opened against latest master and CI checks are green, I'll happily contribute to reviewing it.