Bug 111259 - optional parameters need work
optional parameters need work
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Depends On:
  Show dependency treegraph
Reported: 2003-12-01 10:06 EST by Jeff Johnson
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-05 07:56:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Johnson 2003-12-01 10:06:12 EST
Verification of this bug is really simple in the popt compilation

$ ./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.
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

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 07:56:22 EDT
This problem is fixed in (at least) popt-4.4.6 and later:

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

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