Support Repeated Arguments using standard syntax instead of the non-standard and confusing syntax.
See original GitHub issueUsing 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.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:9
- Comments:14 (6 by maintainers)
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:
POSIX specifies that:
applications using getopt must obey the following syntax guidelines:
in short: Supported option syntax includes short and long form options:
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 :
But the syntax
For example, in the downloader utility of vs2017, I can do:
The standard syntax of the command line:
@ericnewton76
AFAIK, C may be
IEnumerable<string>
{“1”,“2”}, like what is implemented by Microsoft commandLine as described above (accumulative, not overwrite).@duaneking
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.
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.