#10 Check args following -- against defined labeled args when parsing unset, unlabeled args

[Alyssa Garguilo]

As of the moment, arguments following -- are considered by CmdLine's parser if there are still unset, unignorable UnlabeledValueArgs or an unignorable UnlabeledMultiArg has been defined. The first argument encountered following -- is parsed as the first unset, unlabeled argument. This feature could be expanded to add an option check arguments following -- against recognized, labeled arguments.

For example:
$ ./program.exe -- -o output.txt input.txt
If we have defined a ValueArg for our output and an UnlabeledValueArg for our input, "-o" and "output.txt" would be recognized as belonging to the aforementioned ValueArg and would be skipped. "input.txt" is unrecognized and would therefore be parsed as the UnlabeledValueArg.

This feature request was inspired by an entire classroom of undergraduate students, myself included, misinterpretting the usage statement for --: "Ignores the rest of the labeled arguments following this flag." (The feature I've requested is how we thought -- worked already.)

[Mike Smoot]

Ok, it took me several readings of your example to understand what you want. Can you explain why you'd ever want to express a command the way you did in the example? What's the use case? I'm sure there's an edge case I haven't imagined...

Anyway, having gone back and read this, I am strongly disinclined to revisit this awful hack.

That being said, if an enterprising student wanted to submit a patch, I'd be happy to consider it. Although, I really think that just ignoring everthing after -- would probably be better.

[Alyssa Garguilo]

I'm sorry if my wording was unclear - I don't know how I could have phrased that differently.

I've been trying to think of an example use case for the feature I've requested outside of meeting the specifications for the program we were asked to write in the aforementioned class. Correct me if I'm wrong, but my understanding is that TCLAP decided to break from POSIX/GNU standards with regard to -- usage primarily as a workaround to pass command line arguments starting with '-' as UnlabeledValueArgs and UnlabeledMultiArgs. Theoretically, if you implemented my feature request, you could pass a bunch of arguments following -- to the command line and have a function print to stdout which of those arguments were recognized by CmdLine and which of them weren't.¹ I'm not sure why this would ever need to be implemented, but it's doable.

Like I said, the reason this even came up was because my class (professor included) was rather confused when our assignment specifications wanted the feature I'm describing, but TCLAP clearly doesn't actually work that way. My professor put up a "bug bounty" for whomever figured out what was going on and submitted a report - obviously the current implementation isn't a bug, so I submitted a feature request instead and claimed my chocolate this morning. :) I may still write a patch this weekend if I have the time (pointless though it may be), as there's an additional bounty for "fixing" it, and I'd been meaning to get involved in open source projects for a while now anyhow.

I think the real issue here is that the usage entry for -- ("Ignores the rest of the labeled arguments following this flag.") does not make it clear that any arguments that immediately follow -- (regardless of their validity as a labeled argument if the -- flag hadn't been passed) are parsed as unset UnlabeledValueArg(s)/an UnlabeledMultiArg (if they were implemented). I'm not sure how the wording could be changed to reflect this concisely, though. It might be best if -- was changed to be fully compliant with POSIX/GNU standards and a different solution to the "I need to pass arguments with leading dashes" problem was found... Although that sounds like it would require a substantial parser rewrite and would be a huge problem for backwards-compatibility.

¹ A really dumb example:
$ ./program.exe -- -a -b -c -d -e hello -g world
where [-a] and [-c] were valid implementations of SwitchArgs,
[-e <string>] was a valid implementation of a ValueArg,
"-b" and "-d" were not implemented and were therefore interpreted as UnlabeledValueArgs,
"-g" and "world" were not implemented, and all UnlabeledValueArgs were set, so they were interpretted as an UnlabeledMultiArg

[Daniel Aarno]

No worries, and thanks for taking an interrest in TCLAP (fun to learn that you were using it in class). I think the confusion comes from how POSIX treats -- (and perhaps our documentation can be improved). Basically this behavior is defined by the "Utility Conventions" in POSIX (http://bit.ly/1s3UKIu). The relevant section is Guideline 10: "The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character".

This is what we are trying to do, the thing that may be confusing is that since TCLAP is about parsing command line arguments it will grab (as apposed to leave to main) the remaining positional arguments as well. The intended use for this is for example to be able to pass positional arguments that start with a leading '-'. Why is this useful? Imagine you have a file named '-v' (yes with a - in the filename) and you want to sort it:

$ echo -e "c\nb\na" > -v 
$ sort -v
sort: invalid option -- 'v'
Try 'sort --help' for more information.

Now the -- tells sort that -v is actually not an flag, but a positional argument (i.e., the input file)

$sort -- -v
a
b
c

The reason TCLAP grabs the positional arguments after the -- is to make it easy to implement this standard behavior.

[Daniel Aarno]

I think this is working as intended. Re-open if you don't agree.