Allow for prohibiting the no-blank way of specifying short option with option argument

[andy-maier]

The command line parsing implemented by Click allows for specifying a short option followed directly by its option argument without an intervening blank. Click also supports grouping short options behind a single hyphen. These two features together (although they are backed by the POSIX-1.2008 "Command Syntax Guidelines") result in a confusing number of ways to specify short options, that can easily be misunderstood.

Request: I'd like to have a way to define a click option such that it requires at least one whitespace between the option name and its option argument. The default should be the current behavior, so that existing commands behave the same as they do today.

I make this request on the grounds that the "no-blank" rule in the POSIX-1.2008 "Command Syntax Guidelines" was added "to ensure continued operation of historical applications". I think this positioning calls for a way to make this behavior configurable in a parser like Click.

Here is an example script cmd.py, and further down some ways to specify its command line, in order to illustrate why I think it is confusing:

import click

@click.group(invoke_without_command=True)
@click.option('-h', '--host', type=str, default="localhost", metavar="HOST",
              help="Hostname or IP address. Default: localhost.")
@click.option('-v', '--verbose', is_flag=True, default=False,
              help='Verbose mode.')
@click.pass_context
def cli(ctx, host, verbose):
    print("Debug: host=%r, verbose=%r" % (host, verbose))

if __name__ == '__main__':
    cli()

$ cmd.py -h myhost
Debug: host=u'myhost', verbose=False

$cmd.py -hmyhost
Debug: host=u'myhost', verbose=False

$cmd.py -v -h myhost
Debug: host=u'myhost', verbose=True

$cmd.py -vh myhost
Debug: host=u'myhost', verbose=True

$cmd.py -vhmyhost
Debug: host=u'myhost', verbose=True

$cmd.py -hvmyhost
Debug: host=u'vmyhost', verbose=False

The last example is probably not very intuitive to most people, and thus causes confusion.

[untitaker]

I can empathize with that to some extent, but by the same logic it would also be confusing to have option arguments, since it isn't clear at first sight whether an argument belongs to an option, or whether it is a command argument:

foo -v bar

Is bar a @click.argument or the value of -v?

[andy-maier]

I'm not arguing that the command line should be intuitive without reading the command's help. WHat I'm arguing for is to remove confusion that arises despite having read the command's help.

[andy-maier]

The command's help in my examplke command shown above is:

Usage: cmd.py [OPTIONS] COMMAND [ARGS]...

Options:
  -h, --host HOST  Hostname or IP address. Default: localhost.
  -v, --verbose    Verbose mode.
  --help           Show this message and exit.

That does not make it clear that the options can be used in the way I have shown in the invocation examples.

[untitaker]

That's fair, though of course Click isn't exactly alone with this behavior, e.g. -j option of make is very commonly used without space inbetween.

[andy-maier]

According to the POSIX rules I mentioned above, this behavior of make would fall under "ensure continued operation of historical applications".

All I'm asking for is not to be forced to behave like historical applications when I write a new application.

[untitaker]

Sure, I'm not against an option to disable this, though it will have to be off by default since applications are already relying on it.

[andy-maier]

Agreed that it needs to be compatible for existing applications.

[davidism]

Doing this as part of #2205. Another weird behavior this results in is that if ignore_unknown_options is enabled, valid characters can be extracted out of a block of characters, and the remaining will be recombined as a single argument.

For example, if -b and -ac are valid options, and -abc is parsed, -b will be picked up, and -ac will be added to the list of arguments. So -abc test.py can result in an error that test.py is an extra argument, because "-ac" was used as the argument instead.

There are all sorts of weird ambiguities that Click can accept though, not just related to this. We should probably document some recommended strict set of features to enable/disable.