bash: better --optional and <positional> support

[casperdcl]

Bad bash behaviour:

• add_argument("--optional")
  • tries to complete next option/positional rather than wait for input
• add_argument("--optional").complete = shtab.FILE
  • tries to complete next option/positional rather than complete filenames
• add_argument("positional")
  • doesn't respect positional order (e.g. <pos1> <foo> <bar> is indistinguishable from <bar> <pos1> <foo>)
• add_argument("positional1", choices=["one", "two"]); add_argument("positional2")
  • treats one and two as subcommands, so won't complete positional2 (fix AssertionError on valid choices #15)

Note that shtab's zsh completions by comparison work fine (partly due to the fact that zsh itself offers more native completion features).

• find a concise neat example bash completion script which implements these features
• make shtab automatically generate it More robust bash completions generation #38

[bmorledge-hampton19]

In order to better understand this problem, I have a few questions:

1. When a given ArgumentParser objects incorporates subparsers, can it be assumed that the name of a valid subparser (if one is used at all) will be the very first argument after the call to the program itself? (i.e. Do I need to consider the case where the user gives some optional argument for the main parser before giving the name of the desired subparser.)
   • Cases where assumption is valid:
     • [program_name] [subparser_name]
     • [program_name] [--some-optional-argument]
   • Case where assumption is invalid:
     • [program_name] [--some-optional-argument] [subparser_name]
2. Can it be assumed that subparsers will never be nested?
3. Can it be assumed that optional arguments will never precede positional arguments?
   • Cases where assumption is valid:
     • [program_name] [positional_argument_1] [postional_argument_2]
     • [program_name] [subparser_name] [positional_argument_1] [postional_argument_2] [--optional-argument]
   • Cases where assumption is invalid:
     • [program_name] [positional_argument_1] [--optional-argument] [postional_argument_2]
     • [program_name] [--optional-argument] [positional_argument_1] [postional_argument_2]

It would be nice to operate under these assumptions, but with my limited experience with command line interfaces, I am unsure of just how reasonable they are. Any input would be greatly appreciated.

[bmorledge-hampton19]

Actually, scratch that last comment. Looking through the argparse documentation and running some tests, it looks like most of those assumptions are easily broken... I may have a solution though. Stay tuned.

[casperdcl]

Yup argparse is quite flexible and supports all.

[bmorledge-hampton19]

I just realized that the comments I meant to leave here, I accidentally left on issue #37. Regardless, the details are in pull request #38 and I believe they go a long way in fixing this issue.

[casperdcl]

fixed by #38