Bug 111259

Summary: optional parameters need work
Product: [Fedora] Fedora Reporter: Jeff Johnson <jbj>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-05 11:56:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jeff Johnson 2003-12-01 15:06:12 UTC 
Verification of this bug is really simple in the popt compilation
directory:

$ ./test1 --optional --optional
arg1: 0 arg2: (none) oStr: --optional

Obviously, oStr _must_ be "(none)" here as there are not values given
to the
--optional parameter, just like
$ ./test1 --optional
arg1: 0 arg2: (none) oStr: (none)

I guess, popt doesn't check if the next argument is an option (e.g.
beginning
with - or -- but not being "-").
This would mean that parameter with an optional argument can only
appear at
the end and no two of them can be used at the same time. It's very obvious
that this cannot be the wanted behaviour. Also getopt_long does this
correctly 

Was this bug always there or introduced lately?

If there is a working version, how can I check it's version from e.g. an
autoconf script to be able to tell a user to not use a bad version?

My current version of popt is the version in Debian Sarge, namely:
ii  libpopt0       1.7-2          lib for parsing cmdline parameters

Thanks for your support

Hendrik Sattler
Comment 1 Jeff Johnson 2006-08-05 11:56:22 UTC 
This problem is fixed in (at least) popt-4.4.6 and later:

$ ./test1 --optional --optional
arg1: 0 arg2: (none) oStr: (none)