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

Double dash for keyword flags vs single dash for character flags #87

Closed
smousa opened this issue Apr 29, 2014 · 4 comments
Closed

Double dash for keyword flags vs single dash for character flags #87

smousa opened this issue Apr 29, 2014 · 4 comments

Comments

@smousa
Copy link

smousa commented Apr 29, 2014

I noticed that in some applications, character flags are grouped by a single hyphen, while keyword flags must be prepended with a double-hyphen.

For example:
myapp -asdf

Would be the equivalent to:
myapp -a -s -d -f

However,
myapp --asdf

Refers to the keyword flag 'asdf'

Is this something that may be considered for a later version?

@dufferzafar
Copy link

Hmm, this sounds like the correct way to do it. 👍

@kytrinyx
Copy link
Contributor

kytrinyx commented Jul 3, 2014

This is fairly standard in Unix, I think, but in Go it's very common to use a single dash for command line arguments, e.g. go test -run=MyTestName. @codegangsta Do you know if anyone has written up anything about idioms in the Go ecosystem for this sort of thing?

@codegangsta
Copy link
Contributor

I know that the flags package accepts both -- and - for each given flag. I assume this is for practical reasons. Whether someone types --help or -help, the basic assumption is that the user wants see the help.

Sent from my iPhone

On Jul 2, 2014, at 7:28 PM, Katrina Owen notifications@github.com wrote:

This is fairly standard in Unix, I think, but in Go it's very common to use a single dash for command line arguments, e.g. go test -run=MyTestName. @codegangsta Do you know if anyone has written up anything about idioms in the Go ecosystem for this sort of thing?


Reply to this email directly or view it on GitHub.

@jszwedko
Copy link
Contributor

We are at the mercy of the underlying flag parsing library on this one, but I agree that it could be something considered if we ever shifted away to our own parser.

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

5 participants