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).

POPT Library                                           http://rpm5.org
Developer Communication List                       popt-devel@rpm5.org

Reply via email to