commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@imapmail.org>
Subject [CLI] Options without short equivalent
Date Thu, 14 Nov 2002 16:15:29 GMT
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>


Mime
View raw message