gaal / go-options Goto Github PK

I would be great if one could specify optional args. Something like:

d,debug- Turn debugging on

Hello,

when you use a callback parser, there is no other way of stopping parsing the command line arguments than to call os.Exit(). This is inconvenient if you need to do some clean up when you detect that parsing the command line arguments was not successful.

I would like to suggest modifying the signature of the callback parser so that it returns for instance a bool to tell go-options that the parsing process can continue or not.

In the return value of spec.Parse() we would need a way to know if the parsing ended successfully or not. For instance:

spec := options.NewOptions(mySpec).SetParseCallback(MyParseCallback)
opt := spec.Parse(os.Args[1:])
if ! opt.ParsingWasOK() {
// Do some cleanup here
}

In the current situation, we have to call the cleanup process in every 'case' of the 'switch' of the parse callback. If your command accepts several options, this may be a lot of code to repeat.

Best regards,

Hello,

I have been exploring your package for building a command line tool and I find it very useful, so thanks for sharing it.

However, I found a behavior that can be misleading for the future users of my tool. For illustrating it I'm using your example 2.

If you don't provide the value for the option '--output-encoding' which does require a value and provide instead another valid option, such as '--verbose', the '--verbose' string is interpreted as the value of '--output-encoding'. This is a user error for not providing a value and it would be nice to be able to show an appropriate message. See for instance:

$ testGoOptions --output-encoding --verbose
I will concatenate the files: []
Input charset: utf-8
Output charset: --verbose <<<<< '-verbose' is taken as the value of option '--output-encoding'
Chance for a cookie: 0.10

I'm having the same issue with my tool. In the callback function that I provide, I have no easy means to validate that the third argument (i.e. the value of the option) is actually another option, because this information is stored in the OptionSpec type which is opaque.

Would you consider adding a method for OptionSpec that allows callbacks to determine if a given string ('--verbose' in this example) is actually an option? By using this method, my callback would be able to check the option value and display the appropriate message.

Do you see a better way to solve this issue?

Thanks in advance for considering this modification.

The regex which matches option formats slices off the =value for non-option arguments. Sometimes an app wants to have its own internal interpretation of arguments which includes the equals sign.

Expected:
./myprogram --option=value param1=value1 param2=value2
should produce 2 Extra options, namely "param1=value1" and "param2=value2"

Actual:
The result doesn't make sense. I see "value2", "=" in Extra.