Popt has a bug where a short option with an abutting arg is parsed
incorrectly if there is an equal sign in the arg. This can be seen
using the "test1" executable:
% ./test1 -2foo-bar
arg1: 0 arg2: foo-bar
% ./test1 -2foo=bar
test1: bad argument -2foo=bar: invalid numeric value
% ./test1 -21=bar
test1: bad argument -21=bar: unknown option
In the failure cases, the code takes "bar" as the arg to the -2 option,
and then tries to continue parsing the characters that follow the -2
(thus the numeric error for the 'f' option in the first failure, and the
unknown option error for the '=' in the second).
The following patch for 1.14 resets the longArg variable if there was
not a single-dash long-named arg found for an option with a single dash:
--- popt.c.orig 2008-02-16 16:52:18 -0800
+++ popt.c 2008-03-08 00:39:17 -0800
@@ -901,6 +901,7 @@ int poptGetNextOpt(poptContext con)
if (!opt) {
con->os->nextCharArg = origOptString + 1;
+ longArg = NULL;
} else {
if (con->os == con->optionStack && F_ISSET(opt, STRIP))
{
This fixes the problem, and had no adverse affects on any of the various
ways of using -2 and --arg2 (and also -arg2 if POPT_ARGFLAG_ONEDASH is
enabled for that option).
..wayne..
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List [email protected]
