Hadoop Common
  1. Hadoop Common
  2. HADOOP-7995

GenericOptionsParser ought to have better options parsing, and not pick only the options in the front

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 0.23.0
    • Fix Version/s: None
    • Component/s: util
    • Labels:

      Description

      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.

        Issue Links

          Activity

          Hide
          Harsh J added a comment -

          Yes Daryn, that is good enough to close this one out and use as a reference for similar future requests.

          Show
          Harsh J added a comment - Yes Daryn, that is good enough to close this one out and use as a reference for similar future requests.
          Hide
          Daryn Sharp added a comment -

          Here's a few examples of how conflicts may occur if the generic options can appear anywhere in the cmdline:

          • du -D dir
          • ln -fs path

          @Harsh
          Do you feel this is compelling enough to close the jira?

          Show
          Daryn Sharp added a comment - Here's a few examples of how conflicts may occur if the generic options can appear anywhere in the cmdline: du -D dir ln -fs path @Harsh Do you feel this is compelling enough to close the jira?
          Hide
          Daryn Sharp added a comment -

          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.

          Show
          Daryn Sharp added a comment - 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.
          Hide
          Harsh J added a comment -

          Hi,

          I filed this from a discussion with mischat on IRC. We can close it out if there's a strong reason behind not doing this today.

          Its an annoyance but not a bug.

          Show
          Harsh J added a comment - Hi, I filed this from a discussion with mischat on IRC. We can close it out if there's a strong reason behind not doing this today. Its an annoyance but not a bug.
          Hide
          Daryn Sharp added a comment -

          I feel this is a very bad idea... It will interfere with FsShell's parsing of arguments.

          Show
          Daryn Sharp added a comment - I feel this is a very bad idea... It will interfere with FsShell's parsing of arguments.

            People

            • Assignee:
              Unassigned
              Reporter:
              Harsh J
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development