You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/09/10 18:06:37 UTC
proposed: CLI Args improvement
Would it be possible to extend the CLI package in excalibur to
have a CLI Strategy? Basically, there are two common strategies
in CLI parsing:
GNU style (which we support)
Java/CVS style (as-much-as-needed-to-be-unique).
Basically the approach would go like this:
CLOptionDescriptor optionDescriptors = new CLOptionDescriptor[] {
new CLOptionDescriptor("version", 'v', VERSION, "Get the Version and quit"),
new CLOptionDescriptor("valid", 'V', VALID, "Tests to see if the configuration is Valid and quit")
};
parser = new CLArgsParser( args, optionDescriptors, control, CLArgsParser.JAVA_STRATEGY );
// note: for backwards compatibility, the default would be CLArgsParser.AVALON_STRATEGY
This would allow us to parse args in the following manner:
$myapp -ve[rsion]
MyApp Version 1.0
or
$myapp -va[lid]
MyApp Version 1.0
Error in configuration: line 20
By simply switching the strategy to AVALON_STRATEGY (above), we can perform the
following calls:
$myapp (-v | --version)
MyApp Version 1.0
or
$myapp (-V | --valid)
MyApp Version 1.0
Error in configuration: line 20
That way, everyone can be made happy--AND as new strategies for CLI parsing are
uncovered, we can support them easily. This also allows for backwards compatibility.
>From Tom Jordahl in XML-Axis dev:
---------------------------------
FYI
I looked at this code (because I was writing the command line stuff in
wsdl2java) and it is very GNU-like in its option syntax:
-v
--verbose
instead of what we currently have:
-v[erbose]
I am not really in favor of this "two-dash" approach to options, I prefer
(obviously) an "as-much-as needed-to-be-unique" style. If there is strong
sentiment from the group that we want "two-dash" style options, I would be
-1 on it but would still do the work. :-)
I am adding a -package switch today, which is an option that takes an
argument so I maybe I will convince myself I want to switch to Avalon. :-)
--
Tom Jordahl
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: proposed: CLI Args improvement
Posted by Berin Loritsch <bl...@apache.org>.
I wrote a quick little something that would allow something allong the
lines of what I originally proposed. The diff follows:
cvs -z3 diff (in directory C:\projects\jakarta-avalon-excalibur\)
Index: src/java/org/apache/avalon/excalibur/cli/CLArgsParser.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/src/java/org/apache/avalon/excalibur/cli/CLArgsParser.java,v
retrieving revision 1.4
diff -r1.4 CLArgsParser.java
52a53,55
> public static final int AVALON_STRATEGY = 0;
> public static final int JAVA_STRATEGY = 1;
>
75a79
> private final int m_parseStrategy;
137a142
> throws ParseException
139c144
< for( int i = 0; i < m_optionDescriptors.length; i++ )
---
> if (CLArgsParser.JAVA_STRATEGY == m_parseStrategy)
141c146,148
< if( m_optionDescriptors[i].getName().equals( name ) )
---
> CLOptionDescriptor descriptor = null;
>
> for( int i = 0; i < m_optionDescriptors.length; i++ )
143c150,176
< return m_optionDescriptors[i];
---
> if( m_optionDescriptors[i].getName().equals( name ) )
> {
> return m_optionDescriptors[i];
> }
> else if( m_optionDescriptors[i].getName().startsWith( name ) )
> {
> if ( null == descriptor)
> {
> descriptor = m_optionDescriptors[i];
> }
> else
> {
> throw new ParseException( "Ambiguous option: " + name, 0 );
> }
> }
> }
>
> return descriptor;
> }
> else
> {
> for( int i = 0; i < m_optionDescriptors.length; i++ )
> {
> if( m_optionDescriptors[i].getName().equals( name ) )
> {
> return m_optionDescriptors[i];
> }
201a235,249
> this (args, optionDescriptors, control, CLArgsParser.AVALON_STRATEGY);
> }
>
> /**
> * Create a parser that can deal with options and parses certain args.
> *
> * @param args[] the args, typically that passed to the
> * <code>public static void main(String[] args)</code> method.
> * @param optionDescriptors[] the option descriptors
> */
> public CLArgsParser( final String[] args,
> final CLOptionDescriptor[] optionDescriptors,
> final ParserControl control,
> final int parseStrategy )
> {
202a251
> m_parseStrategy = parseStrategy;
245c294
< final int[] incompatible = descriptor.getIncompatble();
---
> final int[] incompatible = descriptor.getIncompatible();
339c388,401
< this( args, optionDescriptors, null );
---
> this( args, optionDescriptors, null, CLArgsParser.AVALON_STRATEGY );
> }
>
> /**
> * Create a parser that deals with options and parses certain args.
> *
> * @param args[] the args
> * @param optionDescriptors[] the option descriptors
> */
> public CLArgsParser( final String[] args,
> final CLOptionDescriptor[] optionDescriptors,
> final int strategy )
> {
> this( args, optionDescriptors, null, strategy );
370c432,448
< * Actually parse arguments
---
> * Parse arguments based on strategy--the default is CLArgsParser.AVALON_STRATEGY
> */
> private void parse()
> throws ParseException
> {
> if (m_parseStrategy == CLArgsParser.JAVA_STRATEGY)
> {
> this.parseJavaStrategy();
> }
> else
> {
> this.parseAvalonStrategy();
> }
> }
>
> /**
> * Actually parse arguments according to CLArgsParser.AVALON_STRATEGY
374c452
< private void parse()
---
> private void parseAvalonStrategy()
404c482
<
---
>
476a555,648
> /**
> * Actually parse arguments according to CLArgsParser.JAVA_STRATEGY
> *
> * @param args[] arguments
> */
> private void parseJavaStrategy()
> throws ParseException
> {
> if( 0 == args.length )
> {
> return;
> }
>
> stringLength = args[ argIndex ].length();
>
> //ch = peekAtChar();
>
> while( true )
> {
> ch = peekAtChar();
>
> //System.out.println( "Pre State=" + m_state );
> //System.out.println( "Pre Char=" + (char)ch + "/" + (int)ch );
>
> if( argIndex >= args.length )
> {
> break;
> }
>
> if( null != m_control && m_control.isFinished( m_lastOptionId ) )
> {
> //this may need mangling due to peeks
> m_unparsedArgs = subArray( args, argIndex, stringIndex );
> return;
> }
>
> //System.out.println( "State=" + m_state );
> //System.out.println( "Char=" + (char)ch + "/" + (int)ch );
>
> if( STATE_NORMAL == m_state )
> {
> parseNormal();
> }
> else if( STATE_NO_OPTIONS == m_state )
> {
> //should never get to here when stringIndex != 0
> addOption( new CLOption( args[ argIndex++ ] ) );
> }
> else if( STATE_OPTIONAL_ARG == m_state && '-' == ch )
> {
> m_state = STATE_NORMAL;
> addOption( m_option );
> }
> else
> {
> parseArguments();
> }
> }
>
> if( m_option != null )
> {
> if( STATE_OPTIONAL_ARG == m_state )
> {
> m_options.addElement( m_option );
> }
> else if( STATE_REQUIRE_ARG == m_state )
> {
> final CLOptionDescriptor descriptor = getDescriptorFor( m_option.getId() );
> final String message =
> "Missing argument to option " + getOptionDescription( descriptor );
> throw new ParseException( message, 0 );
> }
> else if( STATE_REQUIRE_2ARGS == m_state )
> {
> if( 1 == m_option.getArgumentCount() )
> {
> m_option.addArgument( "" );
> m_options.addElement( m_option );
> }
> else
> {
> final CLOptionDescriptor descriptor = getDescriptorFor( m_option.getId() );
> final String message =
> "Missing argument to option " + getOptionDescription( descriptor );
> throw new ParseException( message, 0 );
> }
> }
> else
> {
> throw new ParseException( "IllegalState " + m_state + ": " + m_option, 0 );
> }
> }
> }
>
723c895,906
< parseShortOption();
---
> if (CLArgsParser.JAVA_STRATEGY == m_parseStrategy)
> {
> //its a long option
> final String optionName = nextToken( ARG_SEPARATORS ).getValue();
> final CLOptionDescriptor descriptor = getDescriptorFor( optionName );
> isLong = true;
> parseOption( descriptor, "-" + optionName );
> }
> else
> {
> parseShortOption();
> }
Index: src/test/org/apache/avalon/excalibur/cli/test/ClutilTestCase.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/src/test/org/apache/avalon/excalibur/cli/test/ClutilTestCase.java,v
retrieving revision 1.4
diff -r1.4 ClutilTestCase.java
61a62,66
> private final static String[] ARGLIST6 =
> {
> "-def", "-des", "-c", "-cl"
> };
>
71a77
> private static final int DESCRIBE_OPT = 'd';
77a84,85
> private final static CLOptionDescriptor DESCRIBE =
> new CLOptionDescriptor( "describe", CLOptionDescriptor.ARGUMENT_DISALLOWED, DESCRIBE_OPT, "Describe" );
95a104,105
> private final static CLOptionDescriptor CLEAR6 =
> new CLOptionDescriptor( "clear", CLOptionDescriptor.ARGUMENT_DISALLOWED, CLEAR5_OPT, "r" );
532a543,569
> }
>
> public void testJavaStrategy()
> {
> final CLOptionDescriptor[] options = new CLOptionDescriptor[]
> {
> ClutilTestCase.DESCRIBE,
> new CLOptionDescriptor( "define",
> CLOptionDescriptor.ARGUMENT_DISALLOWED,
> DEFINE_OPT,
> "define" ),
> ClutilTestCase.CLEAR6,
> ClutilTestCase.CLEAR1
> };
>
> final String[] args = ClutilTestCase.ARGLIST6;
>
> final CLArgsParser parser = new CLArgsParser( args, options, CLArgsParser.JAVA_STRATEGY );
>
> assertNull( parser.getErrorString() );
> final List clOptions = parser.getArguments();
>
> assertEquals( clOptions.size(), 4);
> assertEquals( ((CLOption)clOptions.get( 0 )).getId(), ClutilTestCase.DEFINE_OPT );
> assertEquals( ((CLOption)clOptions.get( 1 )).getId(), ClutilTestCase.DESCRIBE_OPT );
> assertEquals( ((CLOption)clOptions.get( 2 )).getId(), ClutilTestCase.CLEAR1_OPT );
> assertEquals( ((CLOption)clOptions.get( 3 )).getId(), ClutilTestCase.CLEAR5_OPT );
---------------------------------------------------
Peter Donald wrote:
>
> On Tue, 11 Sep 2001 02:06, Berin Loritsch wrote:
> > Would it be possible to extend the CLI package in excalibur to
> > have a CLI Strategy?
>
> possible? yes.
>
> > CLOptionDescriptor optionDescriptors = new CLOptionDescriptor[] {
> > new CLOptionDescriptor("version", 'v', VERSION, "Get the Version and
> > quit"), new CLOptionDescriptor("valid", 'V', VALID, "Tests to see if the
> > configuration is Valid and quit") };
>
> Personally I would like to see something more like
>
> CLOptionDescriptor optionDescriptors = new CLOptionDescriptor[] {
> new CLOptionDescriptor( new String[] { "version", "ve" }, 'v',...),
> new CLOptionDescriptor(new String[] { "valid", "va" }, 'V',...)
> };
>
> Because as a program grows more options will be added that could quite
> conceivably alter minimum discerning string which means addition of option
> changes multiple options which is a *bad* idea ;)
>
> Allowing multiple Long forms is much better IMHO
>
> > By simply switching the strategy to AVALON_STRATEGY (above), we can perform
> > the following calls:
>
> Instead of passing a strategy to parser (as I would say the parser *is* the
> strategy) I would make another parser class (maybe JavaCLIParser) and use
> that directly. (Or alternatively use it via utility methods of CLIUtil or
> something). Maybe they could both return a ParserResults or something.
>
> Re: The "java" style
>
> The problem is one of consistency. The "java" style is not consistent. For
> instance in some java apps "uvf" is 3 options while in others it would be
> considered one long option. ie -Dblah is often seen as one option with an
> argument however the "java" style would also allow it to be a single long
> option or multiple short options in a completely application specific manner.
> Theres even more hell to pay with options like -Dblah=blee. There is also no
> way in the "java" style to escape -'s which has bitten me a few times.
>
> > From Tom Jordahl in XML-Axis dev:
> > ---------------------------------
> > FYI
> > I looked at this code (because I was writing the command line stuff in
> > wsdl2java) and it is very GNU-like in its option syntax:
> > -v
> > --verbose
> > instead of what we currently have:
> > -v[erbose]
>
> After the above inconsistency issues are worked out you could implement
> something like that I guess. However the code in CLIParser is extremely ...
> errr ... messy ;) It would probably best just to start a new JavaCLIParser
> from scratch and reuse the option definitions and utility methods etc.
>
> --
> Cheers,
>
> Pete
>
> ------------------------------------------------------------
> militant agnostic: i don't know, and you don't know either.
> ------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: proposed: CLI Args improvement
Posted by Berin Loritsch <bl...@apache.org>.
I wrote a quick little something that would allow something allong the
lines of what I originally proposed. The diff follows:
cvs -z3 diff (in directory C:\projects\jakarta-avalon-excalibur\)
Index: src/java/org/apache/avalon/excalibur/cli/CLArgsParser.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/src/java/org/apache/avalon/excalibur/cli/CLArgsParser.java,v
retrieving revision 1.4
diff -r1.4 CLArgsParser.java
52a53,55
> public static final int AVALON_STRATEGY = 0;
> public static final int JAVA_STRATEGY = 1;
>
75a79
> private final int m_parseStrategy;
137a142
> throws ParseException
139c144
< for( int i = 0; i < m_optionDescriptors.length; i++ )
---
> if (CLArgsParser.JAVA_STRATEGY == m_parseStrategy)
141c146,148
< if( m_optionDescriptors[i].getName().equals( name ) )
---
> CLOptionDescriptor descriptor = null;
>
> for( int i = 0; i < m_optionDescriptors.length; i++ )
143c150,176
< return m_optionDescriptors[i];
---
> if( m_optionDescriptors[i].getName().equals( name ) )
> {
> return m_optionDescriptors[i];
> }
> else if( m_optionDescriptors[i].getName().startsWith( name ) )
> {
> if ( null == descriptor)
> {
> descriptor = m_optionDescriptors[i];
> }
> else
> {
> throw new ParseException( "Ambiguous option: " + name, 0 );
> }
> }
> }
>
> return descriptor;
> }
> else
> {
> for( int i = 0; i < m_optionDescriptors.length; i++ )
> {
> if( m_optionDescriptors[i].getName().equals( name ) )
> {
> return m_optionDescriptors[i];
> }
201a235,249
> this (args, optionDescriptors, control, CLArgsParser.AVALON_STRATEGY);
> }
>
> /**
> * Create a parser that can deal with options and parses certain args.
> *
> * @param args[] the args, typically that passed to the
> * <code>public static void main(String[] args)</code> method.
> * @param optionDescriptors[] the option descriptors
> */
> public CLArgsParser( final String[] args,
> final CLOptionDescriptor[] optionDescriptors,
> final ParserControl control,
> final int parseStrategy )
> {
202a251
> m_parseStrategy = parseStrategy;
245c294
< final int[] incompatible = descriptor.getIncompatble();
---
> final int[] incompatible = descriptor.getIncompatible();
339c388,401
< this( args, optionDescriptors, null );
---
> this( args, optionDescriptors, null, CLArgsParser.AVALON_STRATEGY );
> }
>
> /**
> * Create a parser that deals with options and parses certain args.
> *
> * @param args[] the args
> * @param optionDescriptors[] the option descriptors
> */
> public CLArgsParser( final String[] args,
> final CLOptionDescriptor[] optionDescriptors,
> final int strategy )
> {
> this( args, optionDescriptors, null, strategy );
370c432,448
< * Actually parse arguments
---
> * Parse arguments based on strategy--the default is CLArgsParser.AVALON_STRATEGY
> */
> private void parse()
> throws ParseException
> {
> if (m_parseStrategy == CLArgsParser.JAVA_STRATEGY)
> {
> this.parseJavaStrategy();
> }
> else
> {
> this.parseAvalonStrategy();
> }
> }
>
> /**
> * Actually parse arguments according to CLArgsParser.AVALON_STRATEGY
374c452
< private void parse()
---
> private void parseAvalonStrategy()
404c482
<
---
>
476a555,648
> /**
> * Actually parse arguments according to CLArgsParser.JAVA_STRATEGY
> *
> * @param args[] arguments
> */
> private void parseJavaStrategy()
> throws ParseException
> {
> if( 0 == args.length )
> {
> return;
> }
>
> stringLength = args[ argIndex ].length();
>
> //ch = peekAtChar();
>
> while( true )
> {
> ch = peekAtChar();
>
> //System.out.println( "Pre State=" + m_state );
> //System.out.println( "Pre Char=" + (char)ch + "/" + (int)ch );
>
> if( argIndex >= args.length )
> {
> break;
> }
>
> if( null != m_control && m_control.isFinished( m_lastOptionId ) )
> {
> //this may need mangling due to peeks
> m_unparsedArgs = subArray( args, argIndex, stringIndex );
> return;
> }
>
> //System.out.println( "State=" + m_state );
> //System.out.println( "Char=" + (char)ch + "/" + (int)ch );
>
> if( STATE_NORMAL == m_state )
> {
> parseNormal();
> }
> else if( STATE_NO_OPTIONS == m_state )
> {
> //should never get to here when stringIndex != 0
> addOption( new CLOption( args[ argIndex++ ] ) );
> }
> else if( STATE_OPTIONAL_ARG == m_state && '-' == ch )
> {
> m_state = STATE_NORMAL;
> addOption( m_option );
> }
> else
> {
> parseArguments();
> }
> }
>
> if( m_option != null )
> {
> if( STATE_OPTIONAL_ARG == m_state )
> {
> m_options.addElement( m_option );
> }
> else if( STATE_REQUIRE_ARG == m_state )
> {
> final CLOptionDescriptor descriptor = getDescriptorFor( m_option.getId() );
> final String message =
> "Missing argument to option " + getOptionDescription( descriptor );
> throw new ParseException( message, 0 );
> }
> else if( STATE_REQUIRE_2ARGS == m_state )
> {
> if( 1 == m_option.getArgumentCount() )
> {
> m_option.addArgument( "" );
> m_options.addElement( m_option );
> }
> else
> {
> final CLOptionDescriptor descriptor = getDescriptorFor( m_option.getId() );
> final String message =
> "Missing argument to option " + getOptionDescription( descriptor );
> throw new ParseException( message, 0 );
> }
> }
> else
> {
> throw new ParseException( "IllegalState " + m_state + ": " + m_option, 0 );
> }
> }
> }
>
723c895,906
< parseShortOption();
---
> if (CLArgsParser.JAVA_STRATEGY == m_parseStrategy)
> {
> //its a long option
> final String optionName = nextToken( ARG_SEPARATORS ).getValue();
> final CLOptionDescriptor descriptor = getDescriptorFor( optionName );
> isLong = true;
> parseOption( descriptor, "-" + optionName );
> }
> else
> {
> parseShortOption();
> }
Index: src/test/org/apache/avalon/excalibur/cli/test/ClutilTestCase.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/src/test/org/apache/avalon/excalibur/cli/test/ClutilTestCase.java,v
retrieving revision 1.4
diff -r1.4 ClutilTestCase.java
61a62,66
> private final static String[] ARGLIST6 =
> {
> "-def", "-des", "-c", "-cl"
> };
>
71a77
> private static final int DESCRIBE_OPT = 'd';
77a84,85
> private final static CLOptionDescriptor DESCRIBE =
> new CLOptionDescriptor( "describe", CLOptionDescriptor.ARGUMENT_DISALLOWED, DESCRIBE_OPT, "Describe" );
95a104,105
> private final static CLOptionDescriptor CLEAR6 =
> new CLOptionDescriptor( "clear", CLOptionDescriptor.ARGUMENT_DISALLOWED, CLEAR5_OPT, "r" );
532a543,569
> }
>
> public void testJavaStrategy()
> {
> final CLOptionDescriptor[] options = new CLOptionDescriptor[]
> {
> ClutilTestCase.DESCRIBE,
> new CLOptionDescriptor( "define",
> CLOptionDescriptor.ARGUMENT_DISALLOWED,
> DEFINE_OPT,
> "define" ),
> ClutilTestCase.CLEAR6,
> ClutilTestCase.CLEAR1
> };
>
> final String[] args = ClutilTestCase.ARGLIST6;
>
> final CLArgsParser parser = new CLArgsParser( args, options, CLArgsParser.JAVA_STRATEGY );
>
> assertNull( parser.getErrorString() );
> final List clOptions = parser.getArguments();
>
> assertEquals( clOptions.size(), 4);
> assertEquals( ((CLOption)clOptions.get( 0 )).getId(), ClutilTestCase.DEFINE_OPT );
> assertEquals( ((CLOption)clOptions.get( 1 )).getId(), ClutilTestCase.DESCRIBE_OPT );
> assertEquals( ((CLOption)clOptions.get( 2 )).getId(), ClutilTestCase.CLEAR1_OPT );
> assertEquals( ((CLOption)clOptions.get( 3 )).getId(), ClutilTestCase.CLEAR5_OPT );
---------------------------------------------------
Peter Donald wrote:
>
> On Tue, 11 Sep 2001 02:06, Berin Loritsch wrote:
> > Would it be possible to extend the CLI package in excalibur to
> > have a CLI Strategy?
>
> possible? yes.
>
> > CLOptionDescriptor optionDescriptors = new CLOptionDescriptor[] {
> > new CLOptionDescriptor("version", 'v', VERSION, "Get the Version and
> > quit"), new CLOptionDescriptor("valid", 'V', VALID, "Tests to see if the
> > configuration is Valid and quit") };
>
> Personally I would like to see something more like
>
> CLOptionDescriptor optionDescriptors = new CLOptionDescriptor[] {
> new CLOptionDescriptor( new String[] { "version", "ve" }, 'v',...),
> new CLOptionDescriptor(new String[] { "valid", "va" }, 'V',...)
> };
>
> Because as a program grows more options will be added that could quite
> conceivably alter minimum discerning string which means addition of option
> changes multiple options which is a *bad* idea ;)
>
> Allowing multiple Long forms is much better IMHO
>
> > By simply switching the strategy to AVALON_STRATEGY (above), we can perform
> > the following calls:
>
> Instead of passing a strategy to parser (as I would say the parser *is* the
> strategy) I would make another parser class (maybe JavaCLIParser) and use
> that directly. (Or alternatively use it via utility methods of CLIUtil or
> something). Maybe they could both return a ParserResults or something.
>
> Re: The "java" style
>
> The problem is one of consistency. The "java" style is not consistent. For
> instance in some java apps "uvf" is 3 options while in others it would be
> considered one long option. ie -Dblah is often seen as one option with an
> argument however the "java" style would also allow it to be a single long
> option or multiple short options in a completely application specific manner.
> Theres even more hell to pay with options like -Dblah=blee. There is also no
> way in the "java" style to escape -'s which has bitten me a few times.
>
> > From Tom Jordahl in XML-Axis dev:
> > ---------------------------------
> > FYI
> > I looked at this code (because I was writing the command line stuff in
> > wsdl2java) and it is very GNU-like in its option syntax:
> > -v
> > --verbose
> > instead of what we currently have:
> > -v[erbose]
>
> After the above inconsistency issues are worked out you could implement
> something like that I guess. However the code in CLIParser is extremely ...
> errr ... messy ;) It would probably best just to start a new JavaCLIParser
> from scratch and reuse the option definitions and utility methods etc.
>
> --
> Cheers,
>
> Pete
>
> ------------------------------------------------------------
> militant agnostic: i don't know, and you don't know either.
> ------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: proposed: CLI Args improvement
Posted by Peter Donald <do...@apache.org>.
On Tue, 11 Sep 2001 02:06, Berin Loritsch wrote:
> Would it be possible to extend the CLI package in excalibur to
> have a CLI Strategy?
possible? yes.
> CLOptionDescriptor optionDescriptors = new CLOptionDescriptor[] {
> new CLOptionDescriptor("version", 'v', VERSION, "Get the Version and
> quit"), new CLOptionDescriptor("valid", 'V', VALID, "Tests to see if the
> configuration is Valid and quit") };
Personally I would like to see something more like
CLOptionDescriptor optionDescriptors = new CLOptionDescriptor[] {
new CLOptionDescriptor( new String[] { "version", "ve" }, 'v',...),
new CLOptionDescriptor(new String[] { "valid", "va" }, 'V',...)
};
Because as a program grows more options will be added that could quite
conceivably alter minimum discerning string which means addition of option
changes multiple options which is a *bad* idea ;)
Allowing multiple Long forms is much better IMHO
> By simply switching the strategy to AVALON_STRATEGY (above), we can perform
> the following calls:
Instead of passing a strategy to parser (as I would say the parser *is* the
strategy) I would make another parser class (maybe JavaCLIParser) and use
that directly. (Or alternatively use it via utility methods of CLIUtil or
something). Maybe they could both return a ParserResults or something.
Re: The "java" style
The problem is one of consistency. The "java" style is not consistent. For
instance in some java apps "uvf" is 3 options while in others it would be
considered one long option. ie -Dblah is often seen as one option with an
argument however the "java" style would also allow it to be a single long
option or multiple short options in a completely application specific manner.
Theres even more hell to pay with options like -Dblah=blee. There is also no
way in the "java" style to escape -'s which has bitten me a few times.
> From Tom Jordahl in XML-Axis dev:
> ---------------------------------
> FYI
> I looked at this code (because I was writing the command line stuff in
> wsdl2java) and it is very GNU-like in its option syntax:
> -v
> --verbose
> instead of what we currently have:
> -v[erbose]
After the above inconsistency issues are worked out you could implement
something like that I guess. However the code in CLIParser is extremely ...
errr ... messy ;) It would probably best just to start a new JavaCLIParser
from scratch and reuse the option definitions and utility methods etc.
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: proposed: CLI Args improvement
Posted by Peter Donald <do...@apache.org>.
On Tue, 11 Sep 2001 02:06, Berin Loritsch wrote:
> Would it be possible to extend the CLI package in excalibur to
> have a CLI Strategy?
possible? yes.
> CLOptionDescriptor optionDescriptors = new CLOptionDescriptor[] {
> new CLOptionDescriptor("version", 'v', VERSION, "Get the Version and
> quit"), new CLOptionDescriptor("valid", 'V', VALID, "Tests to see if the
> configuration is Valid and quit") };
Personally I would like to see something more like
CLOptionDescriptor optionDescriptors = new CLOptionDescriptor[] {
new CLOptionDescriptor( new String[] { "version", "ve" }, 'v',...),
new CLOptionDescriptor(new String[] { "valid", "va" }, 'V',...)
};
Because as a program grows more options will be added that could quite
conceivably alter minimum discerning string which means addition of option
changes multiple options which is a *bad* idea ;)
Allowing multiple Long forms is much better IMHO
> By simply switching the strategy to AVALON_STRATEGY (above), we can perform
> the following calls:
Instead of passing a strategy to parser (as I would say the parser *is* the
strategy) I would make another parser class (maybe JavaCLIParser) and use
that directly. (Or alternatively use it via utility methods of CLIUtil or
something). Maybe they could both return a ParserResults or something.
Re: The "java" style
The problem is one of consistency. The "java" style is not consistent. For
instance in some java apps "uvf" is 3 options while in others it would be
considered one long option. ie -Dblah is often seen as one option with an
argument however the "java" style would also allow it to be a single long
option or multiple short options in a completely application specific manner.
Theres even more hell to pay with options like -Dblah=blee. There is also no
way in the "java" style to escape -'s which has bitten me a few times.
> From Tom Jordahl in XML-Axis dev:
> ---------------------------------
> FYI
> I looked at this code (because I was writing the command line stuff in
> wsdl2java) and it is very GNU-like in its option syntax:
> -v
> --verbose
> instead of what we currently have:
> -v[erbose]
After the above inconsistency issues are worked out you could implement
something like that I guess. However the code in CLIParser is extremely ...
errr ... messy ;) It would probably best just to start a new JavaCLIParser
from scratch and reuse the option definitions and utility methods etc.
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
Re: [PATCH] RE: proposed: CLI Args improvement
Posted by Peter Donald <do...@apache.org>.
On Mon, 17 Sep 2001 05:40, Michael McKibben wrote:
> I've attached a patch for CLArgsParser and ClutilTestCase which adds the
> requested feature.
committed - taah!
> In trying to be consistent with getArguments(), I added
> two new methods: getArgumentById(int) and getArgumentByName(String). In
> retrospect, should they be renamed getOptions(), and getOptionByXXX since
> they return CLOption?
Not sure - it prolly does make more sense using "option" - what does everyone
else think?
> The patched ClutilTestCase adds a test case for
> validating the two new methods. I created the patches using cvs diff -u
> relative to the project root directory.
yay!
--
Cheers,
Pete
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
[PATCH] RE: proposed: CLI Args improvement
Posted by Michael McKibben <mi...@hihat.net>.
I've attached a patch for CLArgsParser and ClutilTestCase which adds the
requested feature. In trying to be consistent with getArguments(), I added
two new methods: getArgumentById(int) and getArgumentByName(String). In
retrospect, should they be renamed getOptions(), and getOptionByXXX since
they return CLOption? The patched ClutilTestCase adds a test case for
validating the two new methods. I created the patches using cvs diff -u
relative to the project root directory.
Regards,
--mike
-----Original Message-----
From: Peter Donald [mailto:donaldp@apache.org]
Sent: Monday, September 10, 2001 6:43 PM
To: Avalon Development
Subject: Re: proposed: CLI Args improvement
On Tue, 11 Sep 2001 04:24, hihat@cyan.propagation.net wrote:
> While on the subject of CLI :) I often find it useful get an argument by
> id after parsing. E.g. instead of having to call getArguments() and
> iterate over the Vector, it would be nice to be able to call
> getArgument("file") or getArgument('f'). I will volunteer to submit any
> patch on this if others would find this a useful feature.
Good idea ... will await patch ;)
--
Cheers,
Pete
-----------------------------------------------------------
I don't suffer from insanity. I enjoy every minute of it.
-----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: proposed: CLI Args improvement
Posted by Peter Donald <do...@apache.org>.
On Tue, 11 Sep 2001 04:24, hihat@cyan.propagation.net wrote:
> While on the subject of CLI :) I often find it useful get an argument by
> id after parsing. E.g. instead of having to call getArguments() and
> iterate over the Vector, it would be nice to be able to call
> getArgument("file") or getArgument('f'). I will volunteer to submit any
> patch on this if others would find this a useful feature.
Good idea ... will await patch ;)
--
Cheers,
Pete
-----------------------------------------------------------
I don't suffer from insanity. I enjoy every minute of it.
-----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: proposed: CLI Args improvement
Posted by hi...@cyan.propagation.net.
While on the subject of CLI :) I often find it useful get an argument by
id after parsing. E.g. instead of having to call getArguments() and
iterate over the Vector, it would be nice to be able to call
getArgument("file") or getArgument('f'). I will volunteer to submit any
patch on this if others would find this a useful feature.
Regards,
--mike
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org