Hi,
I've been playing with the CLI library (for almost 24 hours now!) and have stumbled
across a couple of long option related issues
that seem odd. The problems arise because I want to be able to use some options that
have a long option only. I would like to use
long-only options for some options because short ones are in short supply and I would
like to keep options consistent across a suite
of applications (i.e.. -r should not mean recursive to foo while meaning revision to
bar - instead at least one of them should be
expanded into long form only)
Consider trying to mirror subversion's up subcommand, its options are presented below:
Valid options:
-r [--revision] arg : specify revision number ARG (or X:Y range)
-N [--nonrecursive] : operate on single directory only
-q [--quiet] : print as little as possible
--username arg : specify a username ARG
--password arg : specify a password ARG
--no-auth-cache : do not cache authentication tokens
--non-interactive : do no interactive prompting
The first problem: creating the options and displaying the usage information
Options such as revision & quiet are easy:
options.addOption(OptionBuilder
.hasArg()
.withArgName("arg")
.withDescription("specify revision number ARG (or X:Y range)")
.withLongOpt("revision")
.create("r")
);
options.addOption(OptionBuilder
.withDescription("print as little as possible")
.withLongOpt("quiet")
.create("q")
);
Producing usage information of:
-r,--revision <arg> specify revision number ARG (or X:Y range)
-q,--quiet print as little as possible
My first attempt at mirroring username was quite promising:
options.addOption(OptionBuilder
.hasArg()
.withArgName("arg")
.withDescription("specify a username ARG")
.withLongOpt("username")
.create()
);
options.addOption(OptionBuilder
.hasArg()
.withArgName("arg")
.withDescription("specify a password ARG")
.withLongOpt("password")
.create()
);
Output:
--password <arg> specify a password ARG
But only one of them is displayed in the usage information - clearly not good. Is
this a bug in HelpFormatter? it certainly seems
the most intuitive way to add long only options and the parsing works fine. Using the
long version as the create() argument is not
a great work around since the options no longet look like long options - the
distinctive '--' is no longer there.
The second problem: interpretting the results
Once the options are parsed there seems to be no way to check for the values by long
value. This seems odd since checking for the
long names of options would make for more readable code IMHO - e.g. the first of these
two lines reads reasonably while the second
cries out for an additional comment:
if(cmdLine.hasOption("quiet")){...}
if(cmdLine.hasOption("q")){...}
It seems to me that the CommandLine class has been overloaded with loads of
'convenience' methods at the expense of a couple of
useful ones:
public Option getOption(String shortName) & maybe overload with a char version
public Option getLongOption(String longName)
The latter could be implemented by looping through the processed options and checking
invidually but a map lookup would make more
sense.
Third problem: --no-auth-cache doesn't parse
Only bumped into this while writing the email and doesn't really bother me at the
moment (the svn up stuff was just an example and
none of my options have hyphens in them). However I would have thought that long
options wouldn't restrict such characters - is
this a bug or is there a good reason for barfing on this? and if so shouldn't an
IllegalArgumentException be thrown?
I'm happy to work on patches to the above problems but wanted to check that I'm not
being daft first - do others agree with my
percieved bugs or should I be attacking things from another angle? And if i'm to code
any patches then pointers on where to start
would be good :)
Thanks,
Rob
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
