space between flag and argument about go-flags

[jessevdk]

This should normally work, but not for short flags with an optional argument. This is similar in behaviour to gnu getopt. Can you show a short example code for which this fails?

[aktau]

This should normally work, but not for short flags with an optional argument. This is similar in behaviour to gnu getopt. Can you show a short example code for which this fails?

Right, in this case it's an optional argument. I had never noticed that this doesn't work with GNU getopt. So I assume that this is to be expected and there is no workaround? Why would it be so for optional arguments, does it make parsing difficult/impossible?

[jessevdk]

It makes parsing ambiguous. If an argument is optional, you can no longer tell if with "-f config.yml" the config.yml should be the optional argument or a positional argument. Not only is it ambiguous, it also becomes hard to use -f without argument (since it would either always have to appear last, or before another option). Allowing only -f=config.yml removes these issues.

There is no workaround, and I don't think there should be. Maybe in your case the argument should simply not be optional?

[aktau]

It makes parsing ambiguous. If an argument is optional, you can no longer tell if with "-f config.yml" the config.yml should be the optional argument or a positional argument. Not only is it ambiguous, it also becomes hard to use -f without argument (since it would either always have to appear last, or before another option). Allowing only -f=config.yml removes these issues.

I don't entirely understand. If -f is specified, it means that something is going to follow. i.e.: what follows can't be a positional argument. The way I understand it, the flag itself is optional, you can just leave it out. If, however, you DO specify -f, then you also need to supply an argument (it's not a boolean, it's a string).

The only thing left is if the users specifies something after -f that's supposed to be a positional argument. This is a user error, and in this case (as I believe in most cases), the program will just inform the user that that argument doesn't exactly validate.

What do you say?

EDIT: alternatively, there could be a provision for specifying that an argument is itself optional, and not that its value is optional.

[jessevdk]

That's not how optional arguments work. The term optional can be a bit misleading I guess, but the documentation describes it quite clearly. The flag itself is not marked optional, rather the argument to the flag is optional. This means that you can specify only the flag, which will then assume an the value specified in the optional-value tag.

Consider for example this:
Option string short:"o" optional:"yes" optional-value:"something" default:"another thing"

When I would specify only -o, the Option field will be set to "something". However, when I specify -o=value the field will be set to "value". When -o is not specified at all, it will take on the value specified by the default tag, in this case "another thing".

[aktau]

Is suppose such a thing could be useful (different values for absence of flag vis-a-vis flag specified but empty). But in this case I would like a flag that defaults to "config.yml" when it is not present, but when it is present, the user must input a value. i.e.: there would be no "optional-value". Is that possible then?

EDIT: From the examples in README.md:

Supports -I/usr/include -I=/usr/include -I /usr/include option argument specification

Well, the last one is what I need! (how would I go about obtaining such a thing?)

[jessevdk]

Yes, just don't mark it optional, and give it a default value.

[aktau]

Yes, just don't mark it optional, and give it a default value.

Alright, perfect! It somehow doesn't seem to work entirely right when it's used in a command (with AddCommand), but I can easily get around that with this:

if x.Option == "" {
      x.Option = DEFAULT_OPTION
}

So now everything is great, thanks.

[jessevdk]

I see, now that is a bug! I've fixed the defaults for options in commands, so no workaround should be needed anymore.

[aktau]

And that's 3 lines less code, thanks!