Repository navigation
Allow for prohibiting the no-blank way of specifying short option with option argument #742
Description
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.
Activity
untitaker commentedon Feb 22, 2017
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:
Is
bara@click.argumentor the value of-v?andy-maier commentedon Feb 22, 2017
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 commentedon Feb 22, 2017
The command's help in my examplke command shown above is:
That does not make it clear that the options can be used in the way I have shown in the invocation examples.
untitaker commentedon Feb 22, 2017
That's fair, though of course Click isn't exactly alone with this behavior, e.g.
-joption ofmakeis very commonly used without space inbetween.andy-maier commentedon Feb 22, 2017
According to the POSIX rules I mentioned above, this behavior of
makewould 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 commentedon Feb 22, 2017
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 commentedon Feb 22, 2017
Agreed that it needs to be compatible for existing applications.
davidism commentedon Feb 27, 2022
Doing this as part of #2205. Another weird behavior this results in is that if
ignore_unknown_optionsis 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
-band-acare valid options, and-abcis parsed,-bwill be picked up, and-acwill be added to the list of arguments. So-abc test.pycan 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.