[
https://issues.apache.org/jira/browse/CLI-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635449#action_12635449
]
J. Lewis Muir commented on CLI-169:
-----------------------------------
I'd be fine with something like the {{setUseEqualSignWithLongOptions(true)}}
you suggest.
I chose to parameterize the separator to make it a little more flexible. My
idea was to keep the parsers and the formatter decoupled. If some new parser
comes along that accepts options like {{--bsize+<SIZE>}}, then
{{HelpFormatter}} would be able to handle that since the option long
name-argument separator could be set to {{'+'}}.
If there were to be more coupling between the parsers and the formatter, I
could see a {{longOptNameArgSeparator}} property getting added to {{Option}}
and making the parsers use that. Then {{HelpFormatter}} could just always use
the {{longOptNameArgSeparator}} of each option it rendered (like what I
initially did with the value separator).
Anyway, I'd be happy with {{setUseEqualSignWithLongOptions(true)}} you suggest.
> HelpFormatter ignores Option's value separator
> ----------------------------------------------
>
> Key: CLI-169
> URL: https://issues.apache.org/jira/browse/CLI-169
> Project: Commons CLI
> Issue Type: Bug
> Components: Help formatter
> Affects Versions: 1.2
> Reporter: J. Lewis Muir
> Fix For: 1.2
>
> Attachments: long-opt-name-arg-separator.patch,
> use-value-separator-in-help-formatter.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The HelpFormatter always renders a space between the option name and value
> even if the option has a value separator that is not a space. For example,
> this option:
> {code}
> Option option = new Option("B", "bsize", true, "block size in bytes");
> option.setArgName("SIZE");
> option.setValueSeparator('=');
> {code}
> is rendered like this:
> {noformat}
> -B,--bsize <SIZE> block size in bytes
> {noformat}
> But I would expect it to be rendered like this:
> {noformat}
> -B,--bsize=<SIZE> block size in bytes
> {noformat}
> For the automatically generated usage message, a similar problem exists. I
> changed it to try to use the value separator when rendering the option with
> the short name only if there's no long name. If there's no short name, it
> always tries to use the value separator with the long name rendering.
> For example, consider this option containing a short name and a specified
> value separator:
> {code}
> Option option = new Option("B", true, "block size in bytes");
> option.setArgName("SIZE");
> option.setValueSeparator('=');
> {code}
> The automatically generated usage message with my changes would look like
> this:
> {noformat}
> usage: app [-B=<SIZE>]
> {noformat}
> If the same option included a long name too:
> {code}
> Option option = new Option("B", "bsize", true, "block size in bytes");
> option.setArgName("SIZE");
> option.setValueSeparator('=');
> {code}
> with my changes the value separator is assumed to be meant for use with the
> long name. The short option rendering in the usage message will not try to
> use the value separator and will render the usage message like this:
> {noformat}
> usage: app [-B <SIZE>]
> {noformat}
> Attached is a patch for these fixes with test cases. The patch is against
> [http://svn.apache.org/repos/asf/commons/proper/cli/branches/cli-1.x].
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
