This is not the same as passing through unknown options, but it is the convention I am familiar with in large programs with subcommands.

Is this solution satisfactory for you?

The only times I have ever implemented a pass-through option for an options parser was for programs that wrap other command line programs. In these cases, the wrapper had a possibly intersecting superset of options, and I wanted to provide access to the underlying command's options without specifying them in my wrapper.

This worked okay, but the resulting options interface was complex, and since the relationship of the wrapper and underlying command was implicit, a bit fragile.

A major problem with the superset parser was that all unknown options were assumed to require arguments. This is necessary because it is impossible to tell whether `-ab` is meant to be interpreted as `-a -b` or `-a "b"` without knowing whether `-a` requires an argument. We can work around this by requiring that pass-through options always specify option arguments with an equal sign, but now we have introduced subtle differences for different tiers of options.

In contrast to all that, the subcommand options processing style of the git program and others like it allow many intersecting sets of options to be present in a single command invocation simply by following the easily understood convention:

cmd [cmd-opts] subcmd1 [subcmd1-opts] …

I hope you find this argument persuasive, but I am happy to discuss it further!

Sung Pae
added a comment - 10/Dec/13 1:50 PM Hello,
In the next version of tools.cli, parse-opts accepts an :in-order option to process arguments sequentially until the first unknown token.
The README has an explanation:
https://github.com/clojure/tools.cli#in-order-processing-for-subcommands
This is not the same as passing through unknown options, but it is the convention I am familiar with in large programs with subcommands.
Is this solution satisfactory for you?
The only times I have ever implemented a pass-through option for an options parser was for programs that wrap other command line programs. In these cases, the wrapper had a possibly intersecting superset of options, and I wanted to provide access to the underlying command's options without specifying them in my wrapper.
This worked okay, but the resulting options interface was complex, and since the relationship of the wrapper and underlying command was implicit, a bit fragile.
A major problem with the superset parser was that all unknown options were assumed to require arguments. This is necessary because it is impossible to tell whether `-ab` is meant to be interpreted as `-a -b` or `-a "b"` without knowing whether `-a` requires an argument. We can work around this by requiring that pass-through options always specify option arguments with an equal sign, but now we have introduced subtle differences for different tiers of options.
In contrast to all that, the subcommand options processing style of the git program and others like it allow many intersecting sets of options to be present in a single command invocation simply by following the easily understood convention:
cmd [cmd-opts] subcmd1 [subcmd1-opts] …
I hope you find this argument persuasive, but I am happy to discuss it further!