Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Argument/option parameters with hyphens are interpreted as new options #249

Closed
ereyes01 opened this issue Nov 14, 2014 · 2 comments
Closed

Comments

@ereyes01
Copy link

What I'm ultimately trying to do in my particular case is write a process runner using click. Ideally, I'd like to take the trailing end of argv as a list of strings. I'm trying to accomplish this via an argument with nargs=-1. Below is a very simple dumbed-down version that demonstrates my issue:

import click

@click.command()
@click.argument("arg", nargs=-1)
def tasqr_cli(arg):
    click.echo(arg)

This code behaves as follows:

$ python run.py the quick brown fox
('the', 'quick', 'brown', 'fox')

$ python run.py ls -altr
Usage: run.py [OPTIONS] [ARG]...

Error: no such option: -a

Setting the type of "arg" to str didn't make a difference.

You can generalize this test to demonstrate that any argument that starts with a hyphen gives a similar error (i.e. it is interpreted as a missing option), no matter what nargs is set to. So I guess I have a practical question, and a more philosophical design question:

  • Am I using the right approach to accomplish my particular goal of capturing an arbitrary trailing argv of strings?
  • Shouldn't nargs of an option/argument win out over the processing of a new option? Suppose you have something with nargs == 2, if one of those 2 spots were to be a new option, you would have an insufficient number of parameters to the option/argument, right?

I am using Click 3.3 installed via pip/Pypi.

thanks, Eddy

@ereyes01
Copy link
Author

I did find this documentation on the subject, which suggests I need to precede the arbitrary arg list with a --. This is unfortunate for my needs...

Also, that snippet of documentation doesn't quite answer my philosophical question above, though it hints at what the response might be :-)

@ereyes01
Copy link
Author

I think it's clear that this is a design choice in Click, and that it follows the POSIX convention. To do what I want, I must add the -- like this:

python run.py -- ls -altr

FWIW, this is exactly what the POSIX standard specifies for command-line utilities (scroll down and see Section 12.2 Guideline 10).

So the behavior is documented both in Click and in POSIX. I ain't gonna win this argument :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant