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

Already on GitHub? Sign in to your account

Allow required unmatched positional arguments #21

wants to merge 1 commit into


None yet
2 participants

sonnym commented Sep 8, 2012


I have really been enjoying using nomnom, but I have found a use case I was unable to perform. I wanted to allow the user to specify a command, and have a trailing list of unmatched positional arguments, but at least one was required.

The problem therein was that, it is not possible to specify positional arguments that behave this way, as I do not know before hand the index at which they will begin.

I am not sure if this is something you want to pull in, but I think others could find it useful, e.g. as a workaround for #12 . I tried to follow your code conventions, but please let me know if this pull request needs any work - if you decide to pull it in I can document this feature in the README.


@sonnym sonnym allow required unmatched positional arguments
By having a separate spec for positional arguments, it is possible to
have options come before, and then simply use the list of positionals in
_ aftering parsing.

Before this change, it was only posible to specify positional options,
which appear before typical options in the usage output

harthur commented Sep 19, 2012

Do the list: true, required: true options not satisfy your requirements? You can use it with positionals and it will capture an array of all the positionals after a certain position.

Can you give an example use case?

sonnym commented Sep 20, 2012

Thanks for the response on this @harthur - I have really enjoyed working with nomnom thus far.

Those options, unfortunately, do not quite seem to work for me, in terms of I just want to capture all trailing positionals, but I also want at least one to be required.

I am looking more for something along the lines of: git add [options] <list of files> when printing and parsing the help message. I would prefer for them to be trailing positionals, which the pull request attempts to address but with admittedly poor semantics, rather than a separate option such as git add --files list,of.

One problem I encounter with the way positionals currently work is that they have a priority over options, so something that could simply be a mistake like git commit a --amend bar would add both "a" and "bar" to the unmatched positional arguments array.

Ultimately my goal is to have a listing of all positionals after the options - something like a trailing options array - and an error thrown on any unexpected positionals before that point. I am pretty much amenable to any solution, but I do not think nomnom can really handle this use case yet - please let me know if I am being daft and missing something or if you would prefer a different implementation or anything else.

Thanks again!


harthur commented Sep 27, 2012

Okay, thanks for clearing that up. Sorry for not getting back sooner as well, I've been busy at work.

I tended to think that allowing the positionals to be anywhere was a good thing. I think it would be confusing to both allow them everywhere and have some required ones expected to be at the end. Would fixing issue #12 be sufficient for you? I think that would be less confusing.

@sonnym sonnym closed this Jan 25, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment