You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by John Keyes <jb...@mac.com> on 2002/08/05 02:21:19 UTC
[CLI] value separator support
I have added two withValueSeparator method to OptionBuilder. The
no parameter one uses the default value of '='. Here's a usage
example:
Option option = OptionBuilder.withValueSeparator()
.hasArgs()
.create( 'D' );
Options options = new Options().addOption( option );
CommandLineParser parser = CommandLineParserFactory.newParser();
String[] args = new String[] {
"-Dlog4j.configuration=file:log.properties",
"-DJAVA_HOME=/opt/java"
};
CommandLine cmd = parser.parse( args );
// Access the values through the Option itself
for( int i = 0; i < option.getValues().length; i+2 ) {
String property = option.getValue( i );
String value = option.getValue( i + 1 );
}
//Access the values through the CommandLine
Iterator iter = cmd.iterator();
while( iter.hasNext() ) {
Option opt = (Option)iter.next();
switch ( opt.getId() ) {
case 'D':
String[] values = line.getValues( 'D' );
for( int i = 0; i < values.length; i+2 ) {
String property = values[ i ];
String value = values[ i + 1 ];
}
break;
default:
// ...
}
}
There is one issue that I'd like to get people's opinions on. If the
number of arguments for an Option is set and a value is being
split e.g. in the above example if I create the Option withArgs( 3 ),
then the value '/opt/java' cannot be added to the Option. I have
implemented is so any additional values found are added to the
args list but I'm not sure if this is the best thing to do.
Cheers,
-John K
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [CLI] value separator support
Posted by John Keyes <jb...@mac.com>.
On Monday, August 5, 2002, at 03:10 , Berin Loritsch wrote:
>> From: John Keyes [mailto:jbjk@mac.com]
>>
>> I have added two withValueSeparator method to OptionBuilder.
>> The no parameter one uses the default value of '='. Here's a usage
>> example:
>>
>> Option option = OptionBuilder.withValueSeparator()
>> .hasArgs()
>> .create( 'D' );
>>
>> Options options = new Options().addOption( option );
>>
>> CommandLineParser parser = CommandLineParserFactory.newParser();
>>
>> String[] args = new String[] {
>> "-Dlog4j.configuration=file:log.properties",
>> "-DJAVA_HOME=/opt/java"
>> };
>>
>> CommandLine cmd = parser.parse( args );
>>
>> // Access the values through the Option itself
>> for( int i = 0; i < option.getValues().length; i+2 ) {
>> String property = option.getValue( i );
>> String value = option.getValue( i + 1 );
>> }
>>
>> //Access the values through the CommandLine
>> Iterator iter = cmd.iterator();
>> while( iter.hasNext() ) {
>> Option opt = (Option)iter.next();
>> switch ( opt.getId() ) {
>> case 'D':
>> String[] values = line.getValues( 'D' );
>> for( int i = 0; i < values.length; i+2 ) {
>> String property = values[ i ];
>> String value = values[ i + 1 ];
>> }
>> break;
>> default:
>> // ...
>> }
>> }
>>
>> There is one issue that I'd like to get people's opinions on.
>> If the number of arguments for an Option is set and a value
>> is being split e.g. in the above example if I create the
>> Option withArgs( 3 ), then the value '/opt/java' cannot be
>> added to the Option. I have implemented is so any additional
>> values found are added to the args list but I'm not sure if
>> this is the best thing to do.
>
>
> I see. So what you are saying is that if you turn on hasArgs(),
> then every odd entry is the first half, and every even entry is
> the second half.
If you have hasArgs and withValueSeparator this is the case.
> This is different from having multiple instances of the Option
> with the same ID.
Yeap.
> If we had the CommandLineParser have a new instance of the Option
> for every pair, we could limit it with hasArgs(2) and still process
> everything correctly.
This is true. I have been thinking about the multiple instances approach
and how this could be implemented.
> However, by doing it that way, you lose the ability of doing
> CommandLine.getOption("D") and retrieving all the pairs.
I think I will be able to achieve this with the implementation I have
in mind.
> Avalon CLI has the ability to do both approaches, and I believe
> that for the getOption('D') style it only returns the first instance.
>
> The CommandLine object can be adjusted to have a List of Options,
> and keep the order of processing there. It's a thought, however
> its something to weigh out. I personally like the simplicity of
> processing each instance of an Option separately--but I am also
> not the only user either.
Agreed. The approach I take to implementing new features is that
as long as it doesn't affect the APIs that were previously exposed
then just go for it. If it does affect the APIs then mail the list and
trash out the issue.
I'm not satisfied with the implementation of the value separator
stuff. I've embedded it into the parsers but I'd much prefer to
sink this into the Option itself. I like the idea of keeping the parser
code as simple as possible.
So I will be hoping to get this done soon. I will keep you posted on
how it is going.
Thanks,
-John K
p.s. I think I'll have to add you to the contributor list after all of
the help you've been giving me.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [CLI] value separator support
Posted by Berin Loritsch <bl...@apache.org>.
> From: John Keyes [mailto:jbjk@mac.com]
>
> I have added two withValueSeparator method to OptionBuilder.
> The no parameter one uses the default value of '='. Here's a usage
> example:
>
> Option option = OptionBuilder.withValueSeparator()
> .hasArgs()
> .create( 'D' );
>
> Options options = new Options().addOption( option );
>
> CommandLineParser parser = CommandLineParserFactory.newParser();
>
> String[] args = new String[] {
> "-Dlog4j.configuration=file:log.properties",
> "-DJAVA_HOME=/opt/java"
> };
>
> CommandLine cmd = parser.parse( args );
>
> // Access the values through the Option itself
> for( int i = 0; i < option.getValues().length; i+2 ) {
> String property = option.getValue( i );
> String value = option.getValue( i + 1 );
> }
>
> //Access the values through the CommandLine
> Iterator iter = cmd.iterator();
> while( iter.hasNext() ) {
> Option opt = (Option)iter.next();
> switch ( opt.getId() ) {
> case 'D':
> String[] values = line.getValues( 'D' );
> for( int i = 0; i < values.length; i+2 ) {
> String property = values[ i ];
> String value = values[ i + 1 ];
> }
> break;
> default:
> // ...
> }
> }
>
> There is one issue that I'd like to get people's opinions on.
> If the number of arguments for an Option is set and a value
> is being split e.g. in the above example if I create the
> Option withArgs( 3 ), then the value '/opt/java' cannot be
> added to the Option. I have implemented is so any additional
> values found are added to the args list but I'm not sure if
> this is the best thing to do.
I see. So what you are saying is that if you turn on hasArgs(),
then every odd entry is the first half, and every even entry is
the second half.
This is different from having multiple instances of the Option
with the same ID.
If we had the CommandLineParser have a new instance of the Option
for every pair, we could limit it with hasArgs(2) and still process
everything correctly.
However, by doing it that way, you lose the ability of doing
CommandLine.getOption("D") and retrieving all the pairs.
Avalon CLI has the ability to do both approaches, and I believe
that for the getOption('D') style it only returns the first instance.
The CommandLine object can be adjusted to have a List of Options,
and keep the order of processing there. It's a thought, however
its something to weigh out. I personally like the simplicity of
processing each instance of an Option separately--but I am also
not the only user either.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>