Hi Rob,
Comments below.
On Thu, 2002-11-14 at 16:15, Rob Oxspring wrote:
> 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?
This looks like its a bug. I'll have a look at this later this evening.
> 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.
You're constructing them in the correct manner alright.
> 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.
Again, this appears to be a bug, as this should be supported. Again
give me a couple of hours and I'll have a look at it.
> Third problem: --no-auth-cache doesn't parse
I need to add '-' as an allowed character, very simple fix.
> 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?
An IllegalArgumentException should be thrown? I'll check this out too.
> 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 :)
What XXXParser are you using BTW? You can have a go at the patches
yourself if you like but I can get to them this evening.
-John K
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
