DO NOT REPLY [Bug 13933] New: - PosixParser interupts "-target opt" as "-t arget opt"

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13933>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13933

PosixParser interupts "-target opt" as "-t arget opt"

           Summary: PosixParser interupts "-target opt" as "-t arget opt"
           Product: Commons
           Version: Nightly Builds
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: CLI
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: me@joemcglynn.com


This was posted on the Commons-Developer list and confirmed as a bug.

> Is this a bug?  Or am I using this incorrectly?
> I have an option with short and long values.  Given code that is 
> essentially what is below, with a PosixParser I see results as 
> follows:
> 
> A command line with just "-t" prints out the results of the catch 
> block
> (OK)
> A command line with just "-target" prints out the results of the catch
> block (OK)
> A command line with just "-t foobar.com" prints out "processing selected
> target: foobar.com" (OK)
> A command line with just "-target foobar.com" prints out "processing
> selected target: arget" (ERROR?)
> 
> ======================================================================
> ==
> =======================
>   private static final String OPTION_TARGET = "t";
>   private static final String OPTION_TARGET_LONG = "target";
>   // ...
>   Option generateTarget = new Option(OPTION_TARGET, 
>                                      OPTION_TARGET_LONG, 
>                                      true, 
>                                      "Generate files for the specified
> target machine");
>   // ...
>   try {
>         parsedLine = parser.parse(cmdLineOpts, args);
>       } catch (ParseException pe) {
>         System.out.println("Invalid command: " + pe.getMessage() +
> "\n");
>         HelpFormatter hf = new HelpFormatter();
>         hf.printHelp(USAGE, cmdLineOpts);
>         System.exit(-1);
>       }
> 
>   if (parsedLine.hasOption(OPTION_TARGET)) {
>     System.out.println("processing selected target: " +
> parsedLine.getOptionValue(OPTION_TARGET));        
>   }

It is a bug but it is due to well defined behaviour (so that makes me feel a
little better about myself ;).  To support *special* 
(well I call them special anyway) like -Dsystem.property=value we need to be
able to examine the first character of an option.  If the first character is
itself defined as an Option then the remainder of the token is used as the
value, e.g. 'D' is the token, it is an option so 'system.property=value' is the
argument value for that option.  This is the behaviour that we are seeing for
your example.  
't' is the token, it is an options so 'arget' is the argument value.  

I suppose a solution to this could be to have a way to specify properties for
parsers.  In this case 'posix.special.option == true' for turning 
on *special* options. I'll have a look into this and let you know.

Just to keep track of this and to get you used to how we operate, can you log a
bug in bugzilla for this.

Thanks,
-John K

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>