Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.7.0
-
Fix Version/s: 1.7.2, 1.8-beta-1
-
Component/s: None
-
Labels:None
-
Environment:Linux, Mac
-
Testcase included:yes
-
Number of attachments :
Description
When the clibuilder creates a command line option whose longOpt ends with character "s", such as "seconds", the parser can't get the parameter, it is null.
Here's a simple groovy script that demonstrates the problem. Note that the long option ending with an 's' gets enabled when the non-s option is given.
$> ./cli.groovy -s
options.s evaluates to true
options.seconds evaluates to false
options.e evaluates to false
options.second evaluates to false
$> ./cli.groovy -e
options.s evaluates to false
options.seconds evaluates to true
options.e evaluates to true
options.second evaluates to true
def cli = new CliBuilder()
cli.s longOpt:'seconds', 'a long arg that ends with an "s"'
cli.e longOpt:'second', 'a long arg that does not end with an "s"'
def options = cli.parse( args )
if( null == options )
{
return
}
if( args.length == 0 || options.h )
{
cli.usage()
}
println "options.s evaluates to " + (options.s as boolean)
println "options.seconds evaluates to " + (options.seconds as boolean)
println "options.e evaluates to " + (options.e as boolean)
println "options.second evaluates to " + (options.second as boolean)
I don't think that is a bug (may be a documentation issue, but I haven't checked it out yet).
The longOpt(s) is there to support getting multiple option values.
Say, if you have an option (short name = D, long name = define) that lets you pass multiple values with it, you can retrieve them as getOptionValues('D') or options.defines (plural form, that internally maps to getOptionValues('D')) - so it removes last 's', takes the option long name as 'define' and then invokes the getOptionValues() to get all associated values.