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

Multiple longNames #87

Closed
Ponyboy47 opened this issue Sep 13, 2018 · 4 comments
Closed

Multiple longNames #87

Ponyboy47 opened this issue Sep 13, 2018 · 4 comments

Comments

@Ponyboy47
Copy link
Contributor

Not sure if this is part of the POSIX spec or not, but would it be desirable to allow a Flag to have multiple longNames? There are certain abbreviations I use in my scripts for command names, but I like to expose/permit the unabbreviated version as well.
ie: Both --abr value and --average-bit-rate value would be valid

@thii
Copy link
Collaborator

thii commented Sep 14, 2018

Yes, both abbreviated and long version should be permitted. You can take a look at the git commit command as an example. All below do the same thing.

git commit -m add -m file
git commit -m add --message file
git commit --message add --message file

@Ponyboy47
Copy link
Contributor Author

Short names are restricted to a single character though. I'm talking about having more than one long names available for a single flag.
If you notice in my example, both used double dashes and the longName 'abr' would basically be an alias for the longer name 'average-bit-rate'.

ie:

let flag = Flag(longNames: "abr", "average-bit-rate", type: Int.self, description: "The bit rate to which to constrain a video encoding")

@thii
Copy link
Collaborator

thii commented Sep 15, 2018

I couldn't find any documentation about this in the standards. Do you have an example of a utility that allows this?

By the way, I don't think we should allow having more than long names available for a single flag. It would defeat the purpose of the long name is to be descriptive, and would make it harder for documenting.

@Ponyboy47
Copy link
Contributor Author

I can't say that I know of any specific examples and if there's nothing in the standards then I won't push for this. It's not something I specifically need per-say but have found it useful on from time to time.

I do agree that it would make documenting more difficult and after spending a small amount of time seeing if I could implement it, it basically required a substantial rewrite. Definitely not worth the effort for the small amount of benefit in only a small number of situations.

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

No branches or pull requests

2 participants