Possible bug when using subcommands with single option that is part of [options]

[winni2k]

Sorry for the bad title of this issue.

Also thanks for this awesome piece of code.

I'm not sure if this is expected behavior. When I use the following specification on try.docopt.org (docopt 0.6.1):

Usage:
  hi world [--foo=<arg>]
  hi world2 [options]

Options:
    --foo <arg>

, when I type in

world2 --foo bar

I get a usage message, instead of a json parse of the input. I've fiddled around a bit and it appears that this works correctly:

Usage:
  hi world [--foo=<arg>]
  hi world2 [options] [--foo=<arg>]

Options:
    --foo <arg>

Is this a bug or just undocumented behavior?

[itdaniher]

I think this is merely un(der)documented behavior. Looking at the behavior of Docopts, it builds a parse tree corresponding to each line in Usage: and applies the resulting set of structures to the input. With this model - each of your lines (world, world2) are treated as separate subcommands (think git status, git fetch) with different options associated. The [options] shortcut only expands to the set of documented Options not defined elsewhere... this issue is specifically discussed at https://github.com/docopt/docopt/issues/374 https://github.com/docopt/docopt/issues/383 but not called out in the Readme AFAICT.

The behavior you desire could be produced by the following example, with a single parse tree having two optional commands and the same set of arguments:

'''Usage:
  test.py [world | world2] [options]

Options:
    --foo <arg>'''

from docopt import docopt

print(docopt(__doc__))