commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <j...@mac.com>
Subject Re: [CLI] Options without short equivalent
Date Thu, 14 Nov 2002 16:44:30 GMT
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>


Mime
View raw message