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

[Nuno Gonçalves]

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...

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