[CLI]: ParseException:Unrecognized option: -p

[Guillaume Coté]

Hi,

<snip/>

As I already mention in a previous email today, I think there is at
least a documentation bug since the different behavior of each parser
should be clearly explain in the javadoc. (If those difference are
expected.)

Well maybe the documentation just needs to be moved. Check out
the links below for descriptions of what the flatten methods
[1]http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/cli/GnuParser.html#flatten(org.apache.commons.cli.Options,%20java.lang.String[],%20boolean)
[2]http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/cli/PosixParser.html#flatten(org.apache.commons.cli.Options,%20java.lang.String[],%20boolean)
[3]http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/cli/BasicParser.html#flatten(org.apache.commons.cli.Options,%20java.lang.String[],%20boolean)

I check the refered documentation. I still think there is a need for
more documentation, or a different documentation. The method flatten is
protected, so its documentation is intent for developper who need to
overload it (and of course developper who write the class).

Simple user of a parser should not have to understand the implementation
of it to be able to use it. The documentation of the class and its
public method should be enough for anybody to use it, and know which
behavior expected from the class they are using.

For example, I think the documentation of the PosixParser should clearly
state : "That class expect all short option to have a single character".
Also, those all parser assume that a "--" is a long option, or just
the posix.

[John Keyes]

Hi Guillame,

Yeap I agree with you, the user documentation on each parser needs
to be improved. Unfortunately documentation is not my forté so any
submissions on this front are most welcome :-)

Cheers,
-John K

Post by Guillaume Coté
Hi,

<snip/>

As I already mention in a previous email today, I think there is at
least a documentation bug since the different behavior of each
parser should be clearly explain in the javadoc. (If those
difference are expected.)

Well maybe the documentation just needs to be moved. Check out
the links below for descriptions of what the flatten methods
[1]http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/
cli/
GnuParser.html#flatten(org.apache.commons.cli.Options,%20java.lang.Str
ing[],%20boolean)
[2]http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/
cli/
PosixParser.html#flatten(org.apache.commons.cli.Options,%20java.lang.S
tring[],%20boolean)
[3]http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/
cli/
BasicParser.html#flatten(org.apache.commons.cli.Options,%20java.lang.S
tring[],%20boolean)

I check the refered documentation. I still think there is a need for
more documentation, or a different documentation. The method flatten
is protected, so its documentation is intent for developper who need
to overload it (and of course developper who write the class).
Simple user of a parser should not have to understand the
implementation of it to be able to use it. The documentation of the
class and its public method should be enough for anybody to use it,
and know which behavior expected from the class they are using.
For example, I think the documentation of the PosixParser should
clearly state : "That class expect all short option to have a single
character". Also, those all parser assume that a "--" is a long
option, or just the posix.
--
Guillaume Coté
Tel. : [phone]
Fax. : [phone]

- - - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI
http://jakarta.apache.org/commons/cli

[Guillaume Coté]

Hi,

Post by John Keyes
Yeap I agree with you, the user documentation on each parser needs
to be improved. Unfortunately documentation is not my forté so any
submissions on this front are most welcome :-)

I did some thing trying to reverse engineer the parser, but I don't know
if the behavior I have are expected. I got the following error trying
to run the ls test (from ApplicationTest) with a GnuParser or a
BasicParser.

org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option:
--block-size=10
at org.apache.commons.cli.Parser.processOption(Parser.java:253)
at org.apache.commons.cli.Parser.parse(Parser.java:170)
at org.apache.commons.cli.Parser.parse(Parser.java:114)
at org.apache.commons.cli.ApplicationTest.doTestLs(ApplicationTest.java:53)
at
org.apache.commons.cli.ApplicationTest.testLsGnu(ApplicationTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Does all parser support long options?

[John Keyes]

Post by Guillaume Coté
I did some thing trying to reverse engineer the parser, but I don't
know if the behavior I have are expected. I got the following error
trying to run the ls test (from ApplicationTest) with a GnuParser or a
BasicParser.
org.apache.commons.cli.UnrecognizedOptionException: Unrecognized
option: --block-size=10
at org.apache.commons.cli.Parser.processOption(Parser.java:253)
at org.apache.commons.cli.Parser.parse(Parser.java:170)
at org.apache.commons.cli.Parser.parse(Parser.java:114)
at
org.apache.commons.cli.ApplicationTest.doTestLs(ApplicationTest.java:53
)
at
org.apache.commons.cli.ApplicationTest.testLsGnu(ApplicationTest.java:6
3)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
va:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
rImpl.java:25)
Does all parser support long options?

In different ways. BasicParser is a very simple implementation. It
doesn't do
any processing of the command line arguments e.g. in this case
"--block-size=10"
is treated as one token. Therefore, the parser checks to see if there
is an option
names "--block-size=10". Obviously there isn't thus the exception.

GnuParser supports long options but this is the default for Gnu options
e.g.
-buildfile, it doesn't make sense to have a '--buildfile' as well.

PosixParser supports long and short options. So in this case
"--block-size=10"
is burst into two tokens '--block-size' and '10'. The Option
'block-size' can
be found and the '10' is added as an argument value.

Does this answer your question?

-John K

Post by Guillaume Coté
--
Guillaume Coté
Tel. : [phone]
Fax. : [phone]
--

- - - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI
http://jakarta.apache.org/commons/cli