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
[email protected]
https://lists.gnu.org/mailman/listinfo/help-gengetopt
