Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <7160706.1151011590634.JavaMail.jira@brutus>
Date: Thu, 22 Jun 2006 21:26:30 +0000 (GMT+00:00)
From: "Hairong Kuang (JIRA)" <jira@apache.org>
To: commons-dev@jakarta.apache.org
Subject: [jira] Commented: (CLI-12) [cli] Not handling property=value
 followed by 'remaining' args
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/CLI-12?page=comments#action_12417373 ] 

Hairong Kuang commented on CLI-12:
----------------------------------

I came across the same problem. Here is how I would like to solve the problem.

The problem here is that a programmer is not able to specify how an option's argments look like. In the example above, if we can specify that the -D option's arguments should contains a char "=", the parser knows to stop when it comes across an argument that does not contain "=".

I'd like to add to the class Option an API setArgPattern(String argPattern, int limit), in which "argPattern" specifies the pattern that its argments should match and "limit" specifies exact times that the pattern can be applied. For the "-D" option, we should call setArgPattern( "=", 1). The idea is borrow from java String API, split( String regexp, int limit). 

> [cli] Not handling property=value followed by 'remaining' args
> --------------------------------------------------------------
>
>          Key: CLI-12
>          URL: http://issues.apache.org/jira/browse/CLI-12
>      Project: Commons CLI
>         Type: Bug

>  Environment: Operating System: other
> Platform: Other
>     Reporter: Jim Skufca

>
> If you have a command line args similar to
> domything -Dmyprop1=myval1 -Dmyprop2=myval2 myfile
> I would expect to be able to set up the 'D' option so that 
>  String[] opts = line.getOptionValues( "D" );
>  assertEquals( "myprop1", opts[0] );
>  assertEquals( "myval1", opts[1] );
>  assertEquals( "myprop2", opts[2] );
>  assertEquals( "myval2", opts[3] );
>  String[] xtraArgs = line.getArgs();
>  assertEquals( "myfile", xtraArgs[0]);
> But, setting up similar to the ApplicationTest.java I get 'myfile' as opts
> [4].  Since we have set up the 'D' option with hasArgs, it will only stop 
> adding args to 'D' when it runs into another valid option, not an extra arg.  
> If you set up the 'D' option with hasArg (singular) then it myprop1=myval1 
> gets reported as an invalid option.
> I've glanced at the source but didn't see an obvious fix that wouldn't 
> jeopardize the combinations and permutations that Option.addValue() must deal 
> with.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org