Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Date: Tue, 22 Apr 2003 14:45:35 -0500
Message-Id: <H0000b1b2d1b2a08.1051040735.hdqt.cargill.com@MHS>
Subject: unexpected parsing behavior
MIME-Version: 1.0
From: Darin_Hawley@cargill.com
TO: commons-user@jakarta.apache.org
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="BDY.TXT"
	;Creation-Date="Tue, 22 Apr 2003 14:45:35 -0500"
Content-Transfer-Encoding: 7bit


Based on the Usage Scenarios 
(http://jakarta.apache.org/commons/cli/usage.html), (in particular the 
ant example), I was expecting to specify options with long names like 
'buildfile'. The behavior I'm seeing would suggest that option names 
must be a single character. I wrote a simple test program below and got 
the following unexpected results. If nothing else, it would seem that 
the HelpFormatter presents an inconsistent picture of what the parser 
expects. Could someone please clarify and/or update the Usage 
Scenarios? Thanks.

----

java CliTest -test hello
org.apache.commons.cli.UnrecognizedOptionException: Unrecognized 
option: -t
 	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 CliTest.main(CliTest.java:18)
usage: command [options]
  -test <testValue>   a test value

----

import org.apache.commons.cli.*;

public class CliTest {

  public static void main(String[] args) throws Exception {

    Option testOption = OptionBuilder.withArgName("testValue")
      .hasArg().withDescription("a test value")
      .create("test");

    Options options = new Options();
    options.addOption(testOption);

    try {
    
      CommandLineParser parser = new PosixParser();
      CommandLine line = parser.parse(options,args);

    } catch (Exception e) {
      e.printStackTrace();
      new HelpFormatter().printHelp("command [options]", options);
    }
  }
}