[
https://issues.apache.org/jira/browse/HADOOP-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194920#comment-13194920
]
Daryn Sharp commented on HADOOP-7995:
-------------------------------------
I can certainly see how the idea seems attractive on the surface. In fact I
contemplated it during the {{FsShell}} redesign, but parsing all arguments for
generic options may:
* lead to option conflicts, especially if we move to extended option parsing
that uses the least ambiguous shortening of an option, or if we allow option
bundling. Ex. if a subcommand interprets "-fs" as "-f -s", the generic parser
will eat the option as its own "-fs"
* fouling of the subcommand behavior if someone happened to have a path that
matched a generic option
I'd vote to close this jira.
> GenericOptionsParser ought to have better options parsing, and not pick only
> the options in the front
> -----------------------------------------------------------------------------------------------------
>
> Key: HADOOP-7995
> URL: https://issues.apache.org/jira/browse/HADOOP-7995
> Project: Hadoop Common
> Issue Type: Improvement
> Components: util
> Affects Versions: 0.23.0
> Reporter: Harsh J
> Priority: Minor
> Labels: newbie
>
> The ToolRunner provided GenericOptionsParser stops parsing known options when
> it encounters the first unknown option string in the String[] today.
> Ideally we should have it be more intelligent and sift through the whole
> array to pick up all opts, and not just the opts that are at the front of the
> invoked CLI.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
