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.

Sign up for GitHub

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

Jump to bottom

Multiple values separated by a delimiter _only_? #546

Closed
kornelski opened this issue Jun 28, 2016 · 6 comments
Closed

Multiple values separated by a delimiter _only_? #546

kornelski opened this issue Jun 28, 2016 · 6 comments
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-bug Category: Updating dependencies
Milestone
2.8.0

Comments

@kornelski
Copy link
Contributor

I'm trying to make an arg that accepts one or two comma-delimited values, and also accept unnamed (index) argument after that.

prog -q 1,2 file # OK: parses as q=[1,2]; input=file
prog -q 1 file # should parse as q=[1]; input=file; but parses as q=[1,file]; input missing

The problem is that multiple arguments allow spaces, which causes ambiguity. I don't know how to disable that.
@kbknapp
Copy link
Member

kbknapp commented Jun 29, 2016 •
edited
Loading

Currently, there isn't a way to force the use of a delimiter. That is something that could be added.

But there are few other things about this scenario too: Is there a limit on the number of values for q? Otherwise, prog -q 1,2 file won't parse like q=[1,2]; input=file

I could consider this a bug, so-to-speak. i.e. if a delimiter is present, parsing something after a space probably shouldn't be part of the same value group. This still doesn't help your scenario 2 though. To go along with the above "bug" is parsing something like -q=1 file shouldn't lump file in with -q, but currently does.

So, would solving those two bugs suffice, or would a force_delimiter still be preferred? i.e.

  • if a delimiter is present, don't parse anything after a space as the same group of values
  • if a = is present, don't parse anything after a space as the same group of values

This would allow you to do -q=1 file and the option of either -q 1,2 file or -q=1,2 file all parsing correctly.

My only issue with the require_delimiter type thing, is it seems somewhat niche assuming the above bugs are fixed. I would assume most people, upon realizing -q 1 file isn't working would try -q=1 file next.

Edit: thinking about it more, I'm good adding the require_delimiter, but still want some thoughts on the matter :)

@kbknapp kbknapp added C-bug Category: Updating dependencies T: RFC / question A-parsing Area: Parser's logic and needs it changed somehow. labels Jun 29, 2016
@kornelski
Copy link
Contributor Author

kornelski commented Jun 29, 2016 •
edited
Loading

Thank you for your response.

In my case it's strictly 1 or 2 values for q. require_delimiter would be ideal for me, as -q 1 file case is going to be the most common in my program.

kbknapp added a commit that referenced this issue Jun 29, 2016
@kbknapp
fix(Options): using options with an = no longer parse args after the …
290f61d 
…trailing space as values

Imagine two args, an options `-o` and a positionanl arg `<file>` where the option allows multiple
values. Prior to this change the following (incorrect) parses were occurring:

```
$ prog -o=1 some.txt
o = 1, file
file =
```

This change stops parsing values at the space, only if the `=` was used.

```
$ prog -o=1 some.txt
o = 1
file = some.txt
```

Multiple values are still supported via value delimiters

```
$ prog -o=1,2 some.txt
o = 1, 2
file = some.txt
```

Relates to #546
kbknapp added a commit that referenced this issue Jun 29, 2016
@kbknapp
fix(Options): values using delimiters no longer parse additional valu…
cdc500b 
…es after a trailing space

Imagine two args, an option `-o` which accepts mutliple values, and a positional arg `<file>`.
Prior to this change the following (incorrect) parses would have happened:

```
$ prog -o 1,2 some.txt
o = 1, 2, file
file =
```

Only when delimters are used, spaces stop parsing values for the option. The follow are now correct

```
$ prog -o 1,2 some.txt
o = 1, 2
file = some.txt

$ prog some.txt -o 1 2
o = 1, 2
file = some.txt
```

This still has the bi-product of:

```
$ prog -o 1 2 some.txt
o = 1, 2, some.txt
file =
```

This is simply a CLI design and documentation issue (i.e. don't allow options with unlimited
multiple values with positionaln args, or clearly document that positional args go first). This
will also be helped by the upcoming `Arg::require_delimiter`

Relates to #546
@kbknapp
Copy link
Member

kbknapp commented Jun 29, 2016

#547 implements those two bug fixes and will be uploaded to crates.io as v2.7.1, then I'll add the Arg::require_delimiter in a new PR and upload as v2.8.0 to crates.io to keep all SemVer users aware of changes.

@kornelski
Copy link
Contributor Author

Fantastic! Thank you!

@kbknapp
Copy link
Member

kbknapp commented Jun 29, 2016

Arg::require_delimiter isn't implemented yet, doing so now 😉

I want to keep this open just a tracking issue for that, until the PR merges.

@kbknapp kbknapp reopened this Jun 29, 2016
@kbknapp
Copy link
Member

kbknapp commented Jun 30, 2016

This will be fully implemented with #551

@kbknapp kbknapp added this to the 2.8.0 milestone Jun 30, 2016
@homu homu closed this as completed in 98a7e8a Jun 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-bug Category: Updating dependencies
Projects
None yet
Milestone
2.8.0
Development

No branches or pull requests
2 participants
@kornelski @kbknapp