commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [CLI] Making Option Extensible
Date Wed, 24 Jul 2002 14:44:51 GMT
Berin, following your example on GNU options... how do you differentiate:
	-fmyfile.xml -ooutput.xml -Df=bar
	-foD myfile.xml output.xml f=bar
It seems to me like a contradiction that needs to be clarified before
taking up measures for GNU-alike options. Try it yourself:
OK: gmake -n -f -I .
OK: gmake -I.
OK: gmake -nf -I .
ERROR: gmake -nfI .
It seems that GNU options require the value immediately after the
short option flag. The argument value must either follow directly
the flag or as the next argument in the list.

If CLI would allow using a string as the "short" option, then
the java-like options should also work: -classpath ... -verbose -Detc=...
To allow full flexibility/compatibility, the short option should
be an array of strings: e.g. -cp | -classpath | --classpath | -P...

I'm not up-to-date to know if CLI currently allows option catenation
like `make -nf abc.tar`.


Berin Loritsch wrote:
> I heard a rumor that Commons CLI does not support the GNU standards
> on CLI options.  GNU standards have already affected a large number
> of standard software options for UNIX based Oss, and it is a decently
> thought out standard.  The basic gist is this:
> --help
> -h
> The double-dash signifies a long option name, and any arguments for
> the option follow using spaces to separate them from the option name.
> The single-dash signifies a short option name (a single character),
> and any arguments follow directly after the option name.
> Examples of options with arguments:
> --definition foo=bar
> -Dfoo=bar
> --file myfile.xml
> -fmyfile.xml
> We can also combine a number of options after one dash:
> -hDf foo=bar myfile.xml
> All arguments are separated by a space, and are resolved in the order
> that the option is listed.
> Whether you support the decision to use GNU standards or not, they
> should
> not be ignored because they aren't Apache standards.
> I also would argue that the "Java" option style really has no standard.
> All options (short or long) have one dash, but there is no way to
> represent
> a more readable version of a short option or shortcut the typing for a
> long option.  They are what they are.

:) Christoph Reck

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message