Bug 44007 - getopt doesn't operate as described with missing parameter
getopt doesn't operate as described with missing parameter
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-08 17:56 EDT by Tad Marko
Modified: 2016-11-24 09:55 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-08 17:56:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tad Marko 2001-06-08 17:56:14 EDT
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.

How reproducible:
Always

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 
such.
3. run with syntax such as "program -a -c"

Actual Results:  -c will be the parameter for -a.

Expected Results:  getopt should return ':' instead.

Additional info:
Comment 1 Jakub Jelinek 2001-06-10 06:10:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.