You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rob Oxspring <ro...@imapmail.org> on 2002/11/14 17:15:29 UTC
[CLI] Options without short equivalent
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [CLI] Options without short equivalent
Posted by Rob Oxspring <ro...@imapmail.org>.
Thanks John,
I'll have a look at what I can do about the first two items - as an exercise in understanding your code if nothing else.
And as for the third item...
>
> > 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.
Hmmmm as I said - this was an aside that I noticed while documenting the other problems. As such it didn't have the same level of
investigation:
It turns out the long option of no-auth-cache actually parses fine, it looks like I was using the short option work around at the
time, i.e. "-no-auth-cache" doesn't parse which seems pretty reasonable.
Also, I was obviously not concentrating when seeing the parse failure because it does fail fast and the error message I was seeing
was in fact part of an IAE stack trace.
So after all, nothing a cup of coffee and a pair of glasses wouldn't fix ;-)
>
> > 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.
I was using Basic but on more detailed checks demonstrate that Gnu and Posix behave just the same - perfectly reasonably.
Rob (crawling under a rock)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [CLI] Options without short equivalent
Posted by John Keyes <jb...@mac.com>.
Rob,
I've checked in a fix for the second problem you were having,
i.e. using getOptionValues( longOpt ).
I've just seen your mail with the patch for the HelpFormatter
stuff. I'll have a peek at this now and get back to you.
-John K
On Thursday, Nov 14, 2002, at 17:39 Europe/Dublin, Rob Oxspring wrote:
> Thanks John,
>
> I'll have a look at what I can do about the first two items - as an
> exercise in understanding your code if nothing else.
>
> And as for the third item...
>
>>
>>> 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.
>
> Hmmmm as I said - this was an aside that I noticed while documenting
> the other problems. As such it didn't have the same level of
> investigation:
>
> It turns out the long option of no-auth-cache actually parses fine, it
> looks like I was using the short option work around at the
> time, i.e. "-no-auth-cache" doesn't parse which seems pretty
> reasonable.
>
> Also, I was obviously not concentrating when seeing the parse failure
> because it does fail fast and the error message I was seeing
> was in fact part of an IAE stack trace.
>
> So after all, nothing a cup of coffee and a pair of glasses wouldn't
> fix ;-)
>
>>
>>> 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.
>
> I was using Basic but on more detailed checks demonstrate that Gnu and
> Posix behave just the same - perfectly reasonably.
>
> Rob (crawling under a rock)
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
- - - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI
http://jakarta.apache.org/commons/cli
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [CLI] Options without short equivalent
Posted by Rob Oxspring <ro...@imapmail.org>.
Thanks John,
I'll have a look at what I can do about the first two items - as an exercise in understanding your code if nothing else.
And as for the third item...
>
> > 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.
Hmmmm as I said - this was an aside that I noticed while documenting the other problems. As such it didn't have the same level of
investigation:
It turns out the long option of no-auth-cache actually parses fine, it looks like I was using the short option work around at the
time, i.e. "-no-auth-cache" doesn't parse which seems pretty reasonable.
Also, I was obviously not concentrating when seeing the parse failure because it does fail fast and the error message I was seeing
was in fact part of an IAE stack trace.
So after all, nothing a cup of coffee and a pair of glasses wouldn't fix ;-)
>
> > 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.
I was using Basic but on more detailed checks demonstrate that Gnu and Posix behave just the same - perfectly reasonably.
Rob (crawling under a rock)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [CLI] Options without short equivalent
Posted by John Keyes <jb...@mac.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>