[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [help-gengetopt] --unamed-opts
From: |
Lorenzo Bettini |
Subject: |
Re: [help-gengetopt] --unamed-opts |
Date: |
Tue, 30 Apr 2013 10:06:53 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 |
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