Re: [help-gengetopt] --unamed-opts

[Lorenzo Bettini]

On 04/30/2013 10:32 AM, Nuno Gonçalves wrote:
> I'm not sure what you mean.
> 
> getopt is not suppose to trigger any error... It doesn't know if you
> are or not expecting unamed options.
> 
> On the other hand gengetopt knows that you are not expecting them, but
> they were received...
> 

I see what you mean now.

Please file a bug report, but I won't be able to work on that in the
near future (but I can review a patch :)

cheers
        Lorenzo

> Nuno
> 
> On Tue, Apr 30, 2013 at 9:06 AM, Lorenzo Bettini <address@hidden> wrote:
>> Thus, it is the behavior of getopt which does that, right?
>>
>> On 04/30/2013 02:15 AM, Nuno Gonçalves wrote:
>>> I think getopt will strip all the options, and then the unamed options
>>> are left untouched.
>>>
>>> Repoducible example? I think any program where gengetopt was not
>>> called with --unamed-opts.
>>>
>>> Take the example program at
>>> http://www.gnu.org/software/gengetopt/gengetopt.html.
>>>
>>> Call gengetopt without --unamed-opts:
>>>
>>> gengetopt < sample1.ggo --file-name=cmdline1
>>>
>>> Then edit the programa and delete lines 33 and 34. (cause they require
>>> unamed options).
>>>
>>> Now call ./sample1 -i 10 abcd.
>>>
>>> You can see "abcd" is silently ignored.
>>>
>>> Nuno
>>>
>>> On Sun, Apr 28, 2013 at 8:15 AM, Lorenzo Bettini <address@hidden> wrote:
>>>> On 04/27/2013 09:23 AM, Nuno Gonçalves wrote:
>>>>> I'm not sure if --unamed-opts is having the intended behaviour.
>>>>>
>>>>> It is defined as:
>>>>> --unamed-opts
>>>>> the program will accept also options without a name, which, in most
>>>>> case, means that we can pass many file names to the program
>>>>>
>>>>> But I tested that currently if it is not set, but the user still
>>>>> passes unamed options, it does not cause any error when parsing, it
>>>>> just doesn't process them.
>>>>>
>>>>> So I think it should fail the parsing and throw a message that
>>>>> unexpected unamed options were found, or that this description is
>>>>> changed to something that makes that clear:
>>>>>
>>>>> "the program will parse also options without a name, which, in most
>>>>> case, means that we can pass many file names to the program. If not
>>>>> set options without a name are ignored"
>>>>>
>>>>
>>>> mh... I thought it would have reported an error in such case... do you
>>>> have a reproducible example?  Please keep in mind that the actual
>>>> command line options are parsed by getopt_long, not the code generated
>>>> by gengetopt itself; thus, probably, this is the intended behavior from
>>>> getopt_long?
>>>>
>>>> cheers
>>>>         Lorenzo
>>>>
>>>>
>>>> --
>>>> Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
>>>> HOME: http://www.lorenzobettini.it
>>>>
>>>>
>>>> _______________________________________________
>>>> Help-gengetopt mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/help-gengetopt
>>>
>>>
>>>
>>
>>
>> --
>> Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
>> HOME: http://www.lorenzobettini.it
>>
>>
>> _______________________________________________
>> Help-gengetopt mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/help-gengetopt
> 
> _______________________________________________
> Help-gengetopt mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-gengetopt
> 


-- 
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it