Order of options where there are list options and values

[ffadrique]

Hi.

The attached file contains the configuration to parse a number of options that consist of list of elements and finally a list of filenames (after the --).
The problem appear when the last option prior to the -- is a list based option. In that case the parser responds with: 'A required value not bound to option name is missing'

The following command line work with the provided C# configuration:
--modules ../utilities/x64/Debug,../auxtool/x64/Debug --outdir ./x64/Debug -- m_xfunit.f03 m_xfunit_assertion.f03

The following command line does not (with the error mentioned above)
--outdir ./x64/Debug --modules ../utilities/x64/Debug,../auxtool/x64/Debug -- m_xfunit.f03 m_xfunit_assertion.f03

Am I overlooking something or is this an issue or limitation in the software?

Regards,
FranHi.

The attached file contains the configuration to parse a number of options that consist of list of elements and finally a list of filenames (after the --).
The problem appear when the last option prior to the -- is a list based option. In that case the parser responds with: 'A required value not bound to option name is missing'

The following command line work with the provided C# configuration:
--modules ../utilities/x64/Debug,../auxtool/x64/Debug --outdir ./x64/Debug -- m_xfunit.f03 m_xfunit_assertion.f03

The following command line does not (with the error mentioned above)
--outdir ./x64/Debug --modules ../utilities/x64/Debug,../auxtool/x64/Debug -- m_xfunit.f03 m_xfunit_assertion.f03

Am I overlooking something or is this an issue or limitation in the software?

Regards,
Fran
CommandLineOptions.cs.txt

[moh-hassan]

The parser can't isolate the value after list of values because there is no logic rule for value separation.
The solution:

• value is converted to named option.
• use custom type with one string parameter for the list instead of IEnumeable .
  Note: set value index = 0

[ffadrique]

Hi Mohamed,
I am sorry but I have to disagree with your statement. From the design point of view the use of -- should make a difference. The list of items after --modules should be interrupted by the presence of -- where the list of final values in the command line should be started. Otherwise, the presence or absence of -- would make no difference whatsoever.
I have inspected the code and indeed the tokenizer simply ignores the presence of the -- in the command line and then your statement is true that the two lists cannot be told from each other.
I have implemented a small modification (attached) that make the it works in the way I expected (both cases in my original issue behave in the same way as I would expected. It essentially keeps the presence of the -- as an empty token that interrupts the list of items after the --module tag.
The modification is just a trick most likely not good enough for the final implementation but please consider the principle behind. For the time being I'll keep it as workaround in my version.
Kind regards,
Fran

P.S. What different it makes to set value index to 0? I could not find the actual use in the available documentation (maybe my fault not looking in the right place)

Tokenizer.cs.txt
InstanceBuilder.cs.txt

[moh-hassan]

Hi ffadrique

From the design point of view the use of -- should make a difference. The list of items after --modules should be interrupted by the presence of -- where the list of final values in the command line should be started. Otherwise, the presence or absence of -- would make no difference whatsoever.

DoubleDash -- is,in all getopt like tools including this library, used to stop processing Named options and considering them as Values.
All values (until the next -option /--option )is collected in one buffer.
so, your case after dashdash is values:

--outdir ./x64/Debug --modules ../utilities/x64/Debug,../auxtool/x64/Debug -- m_xfunit.f03 m_xfunit_assertion.f03

All these values will be merged together.

I will separate the parts of command with | as seen by any getopt like parser, just for visualization:

| --outdir ./x64/Debug | --modules ../utilities/x64/Debug,../auxtool/x64/Debug  m_xfunit.f03 m_xfunit_assertion.f03|

EDIT:
Really, this issue is reported by more than one: #454, #91 .
A feature will be added to use dashdash as a separator of values

CustumType can help in resolving this use case.
I will provide this solution a little bit

[moh-hassan]

The next custom type can be used instead of IEnumerable, values can be separated by any char (like separator property for IEnumerable<>)

public class ValueList
    {
        // separator between values, space is not allowed. Separators can't be include in values
        public virtual char[] Separator { get; set; } = new[] { ',', ';', ':' };   
        public IEnumerable<string> Value { get; }
        public ValueList(string value) =>  Value = value.Split(Separator);   
    }

Options can be modified as:

 public class CommandLineOptions
    {
  //default is false, no need for Default=false
               [Option("verbose", Required = false,  HelpText = "Generate process tracing information")]
        public bool Verbose { get; set; }
     
        [Option("outdir", Required = false, Default = ".", HelpText = "Directory to look for object file")]
        public String OutDir { get; set; }
       
        [Option("modules", Required = true,  HelpText = "Directories to look for module file")]
        public  ValueList ModuleDirs { get; set; }
        
        [Option("ignore", Required = false,  HelpText = "List of additional module name references to ignore")]
        public ValueList Ignores { get; set; }

        //index 0, because it's the first value starting zero index
        [Value(0, Required = true, HelpText = "List of Fortran source files to process")]
        public ValueList Srcs { get; set; }
    }

In this way Srcs ,ModuleDirs and Ignores can be parsed correctly.

[rmunn]

This should be fixed in the upcoming 2.9 release; you'll need to add EnableDashDash = true to your parser settings to turn on the special handling of the -- separator. Right now that won't fix the bug, but in 2.9 (upcoming) there's a feature to allow the -- to prevent sequences before the -- from consuming values after the --, which should fix this issue.

[rmunn]

There's now a fix for this bug in #684 that does not force you to use EnableDashDash = true. Hopefully #684 will get merged in in time for the upcoming 2.9 release.