You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Guillaume Coté <gc...@experian.fr> on 2002/12/09 11:23:14 UTC

Re: [CLI]: ParseException:Unrecognized option: -p

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
> in each Parser do:
> 
> [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.




-- 
Guillaume Coté
gco@experian.fr
Tel. :  +33.1.41.45.13.87
Fax. :  +33.1.41.45.10.50


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [CLI]: ParseException:Unrecognized option: -p

Posted by John Keyes <jb...@mac.com>.
> 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

>
> -- 
> Guillaume Coté
> gco@experian.fr
> Tel. :  +33.1.41.45.13.87
> Fax. :  +33.1.41.45.10.50
>
>
> --
> 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]: ParseException:Unrecognized option: -p

Posted by Guillaume Coté <gc...@experian.fr>.
Hi,

> 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?

-- 
Guillaume Coté
gco@experian.fr
Tel. :  +33.1.41.45.13.87
Fax. :  +33.1.41.45.10.50


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [CLI]: ParseException:Unrecognized option: -p

Posted by John Keyes <jb...@mac.com>.
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

On Monday, Dec 9, 2002, at 10:23 Europe/Dublin, Guillaume Coté wrote:

> 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
>> in each Parser do:
>> [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é
> gco@experian.fr
> Tel. :  +33.1.41.45.13.87
> Fax. :  +33.1.41.45.10.50
>
>
- - - - - - - - - - - - - - - - - - - - - - -
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>