[MOAB-dev] ProgOptions recognizes negative positional arguments as options

Patrick Shriwise shriwise at wisc.edu
Wed Sep 2 09:24:16 CDT 2015


Iulian

I see. Thats very helpful! Thank you. Would've been nice if that was in 
the documentation, yes. I'm thinking maybe the best place for it to be 
is in the ProgOptions help output.

So right now a program help text looks something like:

GQ: A program for generating generalized quadratic surfaces in CGM.
Usage: gq --help | [options] <A> <B> <C> <D> <E> <F> <G> <H> <J> <K>
Arguments:
   A : x-squared coefficient
   B : y-squared coefficient
   C : z-squared coefficient
   D : xy coefficient
   E : yz coefficient
   F : xz coefficient
   G : x coefficient
   H : y coefficient
   J : z coefficient
   K : offset
Options:
   -h [--help]: Show full help text
   --o <arg>  : Sat File

Maybe we can change the second line to:

Usage: gq --help | [options] -- <A> <B> <C> <D> <E> <F> <G> <H> <J> <K>

Or add a line at the end of the help output:

Use -- to end options in cmd line

Patrick


On 09/01/2015 04:42 PM, Grindeanu, Iulian R. wrote:
> Looking at the code, there is another option you can use
> It is definitely not documented :(
>
> The option is --, to indicate the end of optional arguments,
> (in the code, it turns the boolean "no_more_flags" to true)
> Then all the rest arguments are treated as required positional arguments.
>
> So, in your case, something like
>
> ./prog_opts_bug   --o file.sat --  1 -2 3 4 5 6 7 -8 9 10
>
> would we processed correctly
>
> This assumes that all optional arguments are in the beginning, and all required arguments are at the end
> Optional arguments are followed by --  , which indicates the end of optional arguments
>
> Iulian
> ________________________________________
> From: shriwise [shriwise at wisc.edu]
> Sent: Tuesday, September 01, 2015 2:35 PM
> To: Grindeanu, Iulian R.; moab-dev at mcs.anl.gov
> Subject: Re: [MOAB-dev] ProgOptions recognizes negative positional arguments as options
>
> Iulian,
>
> Attached is a clip from this program which exemplifies the problem.
>
> I have 10 required double options and I use the addRequiredArg method
> for each.
>
> There is one optional argument but its location/presence doesn't seem to
> matter.
>
> The error appears in parseCommandLine. As far as I can tell, this method
> tries to filter out all of the options first and assumes the remaining
> arguments are required positionals.
>
> Negative arguments seem to get picked up as options, returning an error.
>
> Cheers,
>
> Patrick
>
>
> On 09/01/2015 01:43 PM, Grindeanu, Iulian R. wrote:
>> Hi
>> I am not familiar with that class, I think someone in Madison developed it
>> what is your test ?
>> How many "required" double options do you have?
>> Do you use addRequiredArg method? How many times?
>> When does the error appear? (at parsing?) Can you put the "optional" one at the end of the arguments?
>>
>> If you use  addOptionalArgs, do you still see that problem? (I understand you prefer "required", as it is simpler)
>>
>> Iulian
>> ________________________________________
>> From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf of shriwise [shriwise at wisc.edu]
>> Sent: Tuesday, September 01, 2015 12:43 PM
>> To: moab-dev at mcs.anl.gov
>> Subject: [MOAB-dev] ProgOptions recognizes negative positional arguments as     options
>>
>> Hey all,
>>
>> Just noticed this when I was using this incredibly handy class to write
>> a program today.
>>
>> I use it often, but just noticed this today. I have a series of required
>> double arguments and a single option, but when I make one of the doubles
>> negative, ProgOptions tries to evaluate the argument as an option and
>> returns an error.
>>
>> In this case, I've registered one long option with the ProgOptions
>> class. This error occurs whether I specify this option in the command
>> line or not.
>>
>> I've made a few small changes so I can continue to use the class with
>> negative double arguments, but it breaks many of the tests in MOAB.
>>
>> Is anyone more familiar with this class? If not, I can look more deeply
>> into it today/tomorrow and submit a test&fix.
>>
>> Cheers,
>>
>> Patrick
>>
>>
>> --
>> Patrick C. Shriwise
>> Research Fellow
>> University of Wisconsin - Madison
>> Engineering Research Building - Rm. 428
>> 1500 Engineering Drive
>> Madison, WI 53706
>> (608) 446-8173
>>
> --
> Patrick C. Shriwise
> Research Fellow
> University of Wisconsin - Madison
> Engineering Research Building - Rm. 428
> 1500 Engineering Drive
> Madison, WI 53706
> (608) 446-8173
>



More information about the moab-dev mailing list