commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <j...@mac.com>
Subject Re: [CLI] tools usage and parsers
Date Wed, 27 Nov 2002 17:29:37 GMT
Hi Guillaume
On Wed, 2002-11-27 at 10:36, Guillaume Coté wrote:
> When I have idea of possibility of new feature, documentation 
> improvement, test case improvement... for the project, should I enter 
> them directly in bugzilla, or do you prefer that I present them to 
> mailing list?
Bugzilla is what is currently being used.  So that is the best 
place to log bugs or enhancement requests.

> Second, there one thing that I cannot figure out just by reading the 
> javadocs (neither by reading the readme and java source, but I think 
> should be I the javadocs).  Why is there several parser?  Are they 
> supposed to behave the same or not?  If yes, in which case which one are 
> more performent?  If not, what diffence of behavior should I expected 
> from which parser?
Different parsers for different style command lines.  For
example, say I had the following Options:

  Option a = new Option( "a", false, "my a option" );
  Option b = new Option( "b", false, "my b option" );
  Option c = new Option( "c", false, "my c option" );

If I use the PosixParser to parse a command line for this, then
the following args arrays are equivalent:

{ "-abc" }
{ "-a", "-b", "-c" }
{ "-ab", "-c" }
{ "-cba" }

If I use the GnuParser or BasicParser then the following are equivalent:

{ "-a", "-b", "-c" }
{ "-a", "-c", "-b" }
{ "-b", "-c", "-a" }

As you can the PosixParser can 'flatten' command line arguments.
So in the case of 'abc' it would check if 'a' is an Option.  Then
it would check if 'a' can have an argument value.  If it can the
rest of the token is swallowed as the argument value i.e. 'bc'. In
this case it does not have an argument value so the next character
is read, 'b', again this is an Option. If it can take an argument
value then the rest of the token is swallowed as the argument value
i.e. 'c'.  'b' doesn't take an argument so the next character is read,
'c'.

GnuParser only flattens *special* options e.g. -Dtoken=value, if
'D' is an Option and it can take an argument value then the rest of
the token is swallowed as the argument value i.e. "token=value".  If
'D' is not an Option then check if '-Dtoken=value' is an Option.  If
it is not an Option then throw an UnrecognizedOptionException.

BasicParser performs not flattening so all the command line args are
processed as is.

> I am thinking of refactoring the test-case to isolate behavior that are 
> specific to a parser and make sure that any none specific behavior is 
> tested against all parser.
Well the more tests we have the better.  I do aim to get around to doing
this and it would be something like GnuParserTest, BasicParserTest and
PosixParserTest.  These tests would test the flattening algorithms of
these parsers.  Then there would be a ParserTest which tests the 
construction of the CommandLineInstances.

Regards,
-John K

> 
> Thanks
-- 
John Keyes <jbjk@mac.com>


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