Support Repeated Arguments using standard syntax instead of the non-standard and confusing syntax.

Using the newest version, Despite the fact I declared the option as a list in my options class, I’m not able to add multiple options when I use the standard linux command argument patterns, but I am if I use a pattern that breaks compatibility with some accessibility software used by the disabled.

For example the following creates a repeatedoption error:

    public class CommandLineOptions
    {
        [Option('c', "contains", Required = false, Min = 1, Max = 255)]
        public IList<string> Contains { get; set; }
    }

And the command line:

derp.exe  -c "foo" -c "bar"

…Results in an error.

But if I look at the code here on github (because this isn’t documented anywhere I can find, at all, despite being a critical use case) I can get it to work if I do:

derp.exe  -c "foo" "bar"

Respectfully, my first thought on seeing this was “This is a critical defect that explicitly neuters the potential of this library”.

My personal usage goal is in the style of core linux tools like grep, awk, sed, etc. So in my mind this should work exactly like the standard linux flow, where either the last argument wins in the case of only needing one on the command, or in the case of expecting a possible list due to duplicate use of an option, a list should be built up in the order the command line options are used.

Now we can clearly see that this does work, its just using a very inconsistent syntax that doesn’t take into account the needs of screenreaders (So this library technically discriminates against the disabled. Did you know this?) or consistent linux users - look at the standard grep tool, you can use the same argument multiple times and it just works - but only after looking at the source code could I hunt this down because I could not find any data on repeated options or this confusing and inconsistent syntax anywhere in the docs.

Looking at the code, the tests explicitly do not support the industry standard syntax. This is even more frustrating, because its effectively giving the finger to people who want to support accessibility tools that DEPEND on this classic, standard, “last one wins” argument parsing.

This lack of support makes the library unusable for most of the projects I had planned to use it in, and while that hurts me personally, I’m actually more worried about all the people who cant use software that uses this library for argument parsing because of the nonstandard syntax due to a disability that chains them to accessability tools that by default wont understand this non-standard syntax.

So respectfully, I feel like you are shooting yourself in the foot not supporting this, and I would formally like to ask that you support the standard syntax so that more people can actually use this.

[moh-hassan]

I will try match the implementation of CommandLineParser library with the standard of getopt of GNU and POSIX specifications as described in linuxfoundation.org and also described by The Open Group Base Specifications Issue 7, 2018 edition IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)

Option Characteristics GNU specifies that:

• an element of argv that starts with “-” (and is not exactly “-” or “–”) is an option element. YES
• characters of an option element, aside from the initial “-”, are option characters. YES

POSIX specifies that:

applications using getopt must obey the following syntax guidelines:

• option name is a single alphanumeric character from the portable character set YES
• option is preceded by the “-” delimiter character YES
• options without option-arguments should be accepted when grouped behind one “-” delimiter YES
• each option and option-argument is a separate argument YES
• option-arguments are not optional (Yes, controlled with Required)
• all options should precede operands on the command line YES
• the argument “–” is accepted as a delimiter indicating the end of options and the consideration of subsequent arguments, if any, as operands YES
• applications that call any utility with a first operand starting with “-” should usually specify “–” to mark the end of the options. YES Standard utilities that do not support this guideline indicate that fact in the OPTIONS section of the utility description.

in short: Supported option syntax includes short and long form options:

     -a
    -bval
    -b val
   --noarg
   --witharg=val
   --witharg val

Repeating option

There is no standard for the repeating options in the POSIX/getopt and it’s left for the implementer Currently It’s implemented like :

	 -c foo bar 
	 -c foo, bar
	 -c foo;bar  //based on the separator char you define

But the syntax

          -c foo -c bar      //is not implemented and it is nice  to be implemented in the library.

For example, in the downloader utility of vs2017, I can do:

     --add component1 --add component2   //not implemented, it's nice to be implemented
      --add component1  component2    //implemented

The standard syntax of the command line:

               utility_name [-abcDxyz][-p arg][operand]   //operand are the free args

@ericnewton76

derp -c “1” --asdf -c “2”

AFAIK, C may be IEnumerable<string> {“1”,“2”}, like what is implemented by Microsoft commandLine as described above (accumulative, not overwrite).

@duaneking

if a parameter argument is only required once and is used twice, the second usage overwrites the first one and thus the first argument is simply parsed, validated, and then ignored.

It’s accepted if the parameter is defined as string not IEnumerable<string>

In the two cases parser shouldn’t fire error and define the parameter value based on the data type scalar or sequence.

[duaneking]

The support people need is :

derp.exe -c foo-c bar

In this case either both foo and bar would be in the option list (in the case of supporting multiple values in that case) or its simply setting -c to the value of foo then ignoring that and setting the value of -c to bar.