Red Hat Bugzilla – Bug 44007
getopt doesn't operate as described with missing parameter
Last modified: 2016-11-24 09:55:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Description of problem:
The getopt man page claims that getopt returns ':' if an option was
missing a parameter, but this behavior does not occur. getopt simply
returns the next option as the parameter if there is no parameter.
Steps to Reproduce:
1. make a C++ program using getopt (I did not test with a C program) that
prints out the options as processed by getopt.
2. Specify that an option will have a parameter, such as "a:c" or some
3. run with syntax such as "program -a -c"
Actual Results: -c will be the parameter for -a.
Expected Results: getopt should return ':' instead.
No, getopt is right. If optstring is say "a:b" and the arguments
are -a -b, then -b is argument of -a, if you read the man page carefully
(or better yet info libc), you'll see that if option has required
argument, then the required argument is either taken from the rest
of current argument, or next argument.
The missing argument condition happens only if option requiring
argument is the last argument. Furthermore, getopt will even in that
situation return '?', unless the first character in optstring is ':',
in which case. So, if you really want to see getopt return ':',
you should use optstring ":a:b" and pass arguments say -b -a
BTW: This required argument handling is standard, not some GNU
specific feature. E.g. Solaris mentions in getopt(3C) man page that
getopt with optstring, citing:
> Given an option string a:b and the input -a -b, getopt() assumes that -b is
> the mandatory argument to the -a option and not that -a is missing a
> mandatory argument.