Re: Allow equal after a short option
On Sun, Mar 09, 2008 at 07:10:21PM -0400, Jeff Johnson wrote: > Your original patch for -c=foo is now checked in. Cool! You should also be able to uncomment the extra tests now. ..wayne.. __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: Allow equal after a short option
On Mar 9, 2008, at 6:36 PM, Wayne Davison wrote:
On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote:
Running test test1 - 9.
Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1:
0 arg2: foo"
I can get that failure if the line I added does not replace the prior
assignment (which makes it affect the case where *origOptString ==
'\0'
as well as the desired case where it is not '\0').
That's the only explanation I can come up with for why the code would
fail. I have attached a patch that codes up the increment in a
slightly
different way, but I don't see how this change is any different on the
code that follows than what was there before. (Still, I might have
missed something...)
Bingo.
My brain fart, nothing more. Tired old eyes again again, sigh.
Note the missing { ... }, I applied your original patch incorrectly.
Here's the fix:
Index: popt.c
===
RCS file: /v/rpm/cvs/popt/popt.c,v
retrieving revision 1.119
diff -u -b -B -w -p -r1.119 popt.c
--- popt.c 9 Mar 2008 20:24:45 - 1.119
+++ popt.c 9 Mar 2008 23:05:31 -
@@ -932,8 +932,7 @@ int poptGetNextOpt(poptContext con)
origOptString++;
if (*origOptString != '\0')
- con->os->nextCharArg = origOptString;
-#ifdef NOTYET /* XXX causes test 9 failure. */
+#ifndefNOTYET /* XXX causes test 9 failure. */
con->os->nextCharArg = origOptString +
(*origOptString == '=');
#endif
}
Your original patch for -c=foo is now checked in.
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List [email protected]
Re: echo incompatibility (was Re: Allow equal after a short option)
On Mar 9, 2008, at 6:22 PM, Wayne Davison wrote: On Sun, Mar 09, 2008 at 10:51:42AM -0400, Jeff Johnson wrote: [EMAIL PROTECTED] popt]$ /bin/echo --foo --bar --bar [EMAIL PROTECTED] popt]$ /bin/echo -- --foo --bar --foo --bar OK, Let's hope that your echo will not drop anything if the first arg passed to it is a non-option (such as "args:"). If so, the attached patch should work for everyone (it does for me). Clever hack to change the 1st arg to echo ... However, not-POSIXLY_CORRECT rearrangements _SHOULD_ cause argument permutation with, say, /bin/echo args: A -b C -d --foo --bar afaict that may exhibit the same failure lossage as before. Dunno, non-POSIXLY_CORRECT echo(1) argument processing definition(s) I'll leave to LSB-53, "unspecified" behavior is gud enuf for me. The better fix (for me as well as popt) is to get a non-Fedora enhanced /bin/echo ... todo++. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: Allow equal after a short option
On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote:
> Running test test1 - 9.
> Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1:
> 0 arg2: foo"
I can get that failure if the line I added does not replace the prior
assignment (which makes it affect the case where *origOptString == '\0'
as well as the desired case where it is not '\0').
That's the only explanation I can come up with for why the code would
fail. I have attached a patch that codes up the increment in a slightly
different way, but I don't see how this change is any different on the
code that follows than what was there before. (Still, I might have
missed something...)
..wayne..
--- popt.c 9 Mar 2008 20:24:45 - 1.119
+++ popt.c 9 Mar 2008 22:15:08 -
@@ -931,11 +931,11 @@ int poptGetNextOpt(poptContext con)
shorty = 1;
origOptString++;
- if (*origOptString != '\0')
+ if (*origOptString != '\0') {
+ if (*origOptString == '=')
+ origOptString++;
con->os->nextCharArg = origOptString;
-#ifdef NOTYET /* XXX causes test 9 failure. */
- con->os->nextCharArg = origOptString + (*origOptString == '=');
-#endif
+ }
}
if (opt == NULL) return POPT_ERROR_BADOPT; /* XXX can't happen */
echo incompatibility (was Re: Allow equal after a short option)
On Sun, Mar 09, 2008 at 10:51:42AM -0400, Jeff Johnson wrote: > [EMAIL PROTECTED] popt]$ /bin/echo --foo --bar > --bar > [EMAIL PROTECTED] popt]$ /bin/echo -- --foo --bar > --foo --bar OK, Let's hope that your echo will not drop anything if the first arg passed to it is a non-option (such as "args:"). If so, the attached patch should work for everyone (it does for me). ..wayne.. --- test-poptrc 16 Feb 2008 22:16:10 - 1.4 +++ test-poptrc 9 Mar 2008 22:15:08 - @@ -7,6 +7,6 @@ test1 alias -O --arg1 test1 alias --grab --arg2 "'foo !#:+'" test1 alias --grabbar --grab bar -test1 exec --echo-args echo -- +test1 exec --echo-args echo args: test1 alias -e --echo-args -test1 exec -a /bin/echo -- +test1 exec -a /bin/echo args: --- testit.sh 8 Mar 2008 23:11:56 - 1.24 +++ testit.sh 9 Mar 2008 22:15:08 - @@ -68,11 +68,11 @@ POSIXLY_CORRECT=1 ; export POSIXLY_CORRE run test1 "test1 - 17" "arg1: 1 arg2: (none) rest: foo --arg2 something" --arg1 foo --arg2 something unset POSIXLY_CORRECT run test1 "test1 - 18" "callback: c sampledata bar arg1: 1 arg2: (none)" --arg1 --cb bar -run test1 "test1 - 19" "" --echo-args -run test1 "test1 - 20" "--arg1" --echo-args --arg1 -run test1 "test1 - 21" "--arg2 something" -T something -e -run test1 "test1 - 22" "--arg2 something more args" -T something -a more args -run test1 "test1 - 23" "--echo-args -a" --echo-args -e -a +run test1 "test1 - 19" "args:" --echo-args +run test1 "test1 - 20" "args: --arg1" --echo-args --arg1 +run test1 "test1 - 21" "args: --arg2 something" -T something -e +run test1 "test1 - 22" "args: --arg2 something more args" -T something -a more args +run test1 "test1 - 23" "args: --echo-args -a" --echo-args -e -a run test1 "test1 - 24" "arg1: 0 arg2: (none) short: 1" -onedash run test1 "test1 - 25" "arg1: 0 arg2: (none) short: 1" --onedash run test1 "test1 - 26" "callback: c arg for cb2 foo arg1: 0 arg2: (none)" --cb2 foo
Re: Allow equal after a short option
On Mar 9, 2008, at 5:38 PM, Wayne Davison wrote: On Sun, Mar 09, 2008 at 10:51:42AM -0400, Jeff Johnson wrote: Meanwhile, below is a rewrite of POPT_fprintf, essentially identical to the "man vsnprintf" example. See what you think ... Looks good. I did some tweaking based on this code. The attached patch changes what you checked-in to CVS. See if you agree with these points: 1. If the system has vasprintf(), just use that (avoiding issues 2 & 3). Agreed. 2. Always allocate one more byte than we need, just in case the system's vsprintf() has an off-by-one bug with the limit. That's kinda nutty (but hurts nothing). I'd rather fix a known problem rather than trying to anticipate all possibilities ... 3. Moved the va_start() and va_end() calls back in the loop because I believe that the systems that needed a va_copy() in the old code won't like the reuse of "ap" without it. ... afaik 3) is vs implementation dependent confusion with va_start() and va_end(). But hurts nothing at all ... Bonus question: I didn't think older systems supported the idiom of realloc(NULL, len) doing a malloc(). I didn't check to see if that idiom is already used elsewhere in the popt code, though, so I just left that alone. ... and my ultimate answer is: Deranged and ancient uglix-like systems, with busted vsnpprintf and other damage, can certainly live with gud old fprintf(3) as popt _USED_ to do without all this dain bread conversion from UTF-* to the native locale using iconv & vsnprintf & nl_langinfo & wide characters & malloc'ing fprintf's & None of this modern crapola existed on systems that had busted v*printf() implementations, almost all the problems disappear with #define POPT_fprintffprintf (and some tweaks to test whether POPT_fprintf is defined). KISS is always better ... I tested both sides of the HAVE_VASPRINTF code and this seems good to me. Off to tweak in vasprintf(3) ... I am happy to see sprintf start to vanish ... 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: Allow equal after a short option
On Sun, Mar 09, 2008 at 10:51:42AM -0400, Jeff Johnson wrote:
> Meanwhile, below is a rewrite of POPT_fprintf, essentially identical
> to the "man vsnprintf" example. See what you think ...
Looks good. I did some tweaking based on this code. The attached patch
changes what you checked-in to CVS. See if you agree with these points:
1. If the system has vasprintf(), just use that (avoiding issues 2 & 3).
2. Always allocate one more byte than we need, just in case the system's
vsprintf() has an off-by-one bug with the limit.
3. Moved the va_start() and va_end() calls back in the loop because I
believe that the systems that needed a va_copy() in the old code
won't like the reuse of "ap" without it.
Bonus question: I didn't think older systems supported the idiom of
realloc(NULL, len) doing a malloc(). I didn't check to see if that
idiom is already used elsewhere in the popt code, though, so I just
left that alone.
I tested both sides of the HAVE_VASPRINTF code and this seems good to
me.
..wayne..
--- configure.ac9 Mar 2008 20:24:45 - 1.39
+++ configure.ac9 Mar 2008 21:26:17 -
@@ -69,7 +69,7 @@ AM_CONDITIONAL(HAVE_LD_VERSION_SCRIPT, t
AC_CHECK_FUNC(setreuid, [], [
AC_CHECK_LIB(ucb, setreuid, [if echo $LIBS | grep -- -lucb >/dev/null
;then :; else LIBS="$LIBS -lc -lucb" USEUCB=y;fi])
])
-AC_CHECK_FUNCS(getuid geteuid iconv mtrace __secure_getenv setregid stpcpy
strerror)
+AC_CHECK_FUNCS(getuid geteuid iconv mtrace __secure_getenv setregid stpcpy
strerror vasprintf)
AM_GNU_GETTEXT([external])
--- poptint.c 9 Mar 2008 20:24:45 - 1.17
+++ poptint.c 9 Mar 2008 21:26:18 -
@@ -152,13 +152,17 @@ int
POPT_fprintf (FILE * stream, const char * format, ...)
{
char * b = NULL, * ob = NULL;
-size_t nb = (size_t)1;
int rc;
va_list ap;
+#ifndef HAVE_VASPRINTF
+size_t nb = (size_t)1;
-va_start(ap, format);
-while ((b = realloc(b, nb)) != NULL) {
+/* Note that we always allocate 1 byte more than we need, just in
+ * case the vsnprintf() has an off-by-one bug with the limit. */
+while ((b = realloc(b, nb+1)) != NULL) {
+ va_start(ap, format);
rc = vsnprintf(b, nb, format, ap);
+ va_end(ap);
if (rc > -1) { /* glibc 2.1 */
if ((size_t)rc < nb)
break;
@@ -167,8 +171,16 @@ POPT_fprintf (FILE * stream, const char
nb += (nb < (size_t)100 ? (size_t)100 : nb);
ob = b;
}
+
+#else /* HAVE_VASPRINTF */
+
+va_start(ap, format);
+if (vasprintf(&b, format, ap) < 0)
+ b = NULL;
va_end(ap);
+#endif
+
rc = 0;
if (b != NULL) {
#ifdef HAVE_ICONV
RE: Allow equal after a short option
> [EMAIL PROTECTED] popt]$ /bin/echo --foo --bar > --bar > [EMAIL PROTECTED] popt]$ /bin/echo -- --foo --bar > --foo --bar > Heh, I believe the answer starts to become clearer: > The echo(1) from Fedora coreutils-6.10-4.fc9.i386 dares to be different. > The root cause is what I needed to understand. Thanks for the patience. That is not cool (swallowing the first long option), especially since the echo built in to bash continues to work as it has. I also observe this behavior on F8. On the other hand, not emitting the -- seems reasonable, since it generically has the meaning "this signals the end of the options". (And no, that's not how it works anywhere else, including bash and ksh's echo on F8). __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: Allow equal after a short option
On Mar 9, 2008, at 10:51 AM, Jeff Johnson wrote:
while ((b = realloc(b, nb)) != NULL) {
va_start(ap, format);
rc = vsnprintf(b, nb, format, ap);
va_end(ap);
if (rc < -1 && (size_t)rc < nb)
This should have been
if (rc > -1 && (size_t)rc < nb)
break;
if (rc > -1)/* glibc 2.1 */
nb = rc + 1;
else/* glibc 2.0 */
nb += (nb <= 1 ? 100 : nb);
ob = b;
}
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List [email protected]
Re: Allow equal after a short option
On Mar 9, 2008, at 10:14 AM, Wayne Davison wrote:
On Sun, Mar 09, 2008 at 12:42:37AM -0500, Jeff Johnson wrote:
/bin/echo on my system is unmodified from
Fedora 9 coreutils-6.10-4.fc9.i386
Interesting. So, what do you get with a manual run?
/bin/echo --foo --bar
/bin/echo -- --foo --bar
[EMAIL PROTECTED] popt]$ /bin/echo --foo --bar
--bar
[EMAIL PROTECTED] popt]$ /bin/echo -- --foo --bar
--foo --bar
Heh, I believe the answer starts to become clearer:
The echo(1) from Fedora coreutils-6.10-4.fc9.i386 dares to be
different.
The root cause is what I needed to understand. Thanks for the patience.
I see all the option information output literally, including the --.
What do you get if you try a "make check" using that perl -e patch
instead of echo? Does it still succeed for you?
I added the longArg = NULL, am seeing the same failure on test # 9.
Very weird. I don't see how my change could affect a short option's
separated arg. Attached is an even safer version of the change that
ensures that the only time it ever sets longArg to NULL is if the
longArg was set to oe + 1 upon finding an equal sign.
I also tried using valgrind in the test suite:
result=`valgrind $builddir/$prog $*`
and the test-run didn't turn up any errors.
Your
longArg = NULL;
patch seems fine. The issue I'm seeing is here:
...
origOptString++;
if (*origOptString != '\0')
con->os->nextCharArg = origOptString;
#ifdef NOTYET /* XXX causes test 9 failure. */
con->os->nextCharArg = origOptString +
(*origOptString == '=');
#endif
}
if (opt == NULL) return POPT_ERROR_BADOPT; /* XXX can't
happen */
...
If I turn that line on, popt "make check" (and rpm -q) breaks.
There's a class of problems, particularly with recursions like popt,
that can fool valgrind.
Meanwhile, below is a rewrite of POPT_fprintf, essentially identical
to the "man vsnprintf"
example. See what you think ...
(aside) I swear I wrote this code before, likely early June 2007,
when the need for va_copy
on amd64/ppc was discovered. The issue was discussed at some length
on <[EMAIL PROTECTED]>
during the 1st two weeks of June 2007.
int
POPT_fprintf (FILE * stream, const char * format, ...)
{
char * b = NULL, * ob = NULL;
size_t nb = 1;
int rc;
va_list ap;
while ((b = realloc(b, nb)) != NULL) {
va_start(ap, format);
rc = vsnprintf(b, nb, format, ap);
va_end(ap);
if (rc < -1 && (size_t)rc < nb)
break;
if (rc > -1)/* glibc 2.1 */
nb = rc + 1;
else/* glibc 2.0 */
nb += (nb <= 1 ? 100 : nb);
ob = b;
}
rc = 0;
if (b != NULL) {
#ifdef HAVE_ICONV
ob = strdup_locale_from_utf8(b);
if (ob != NULL) {
rc = fprintf(stream, "%s", ob);
free(ob);
} else
#endif
rc = fprintf(stream, "%s", b);
free (b);
} else if (ob != NULL)
free(ob);
return rc;
}
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List [email protected]
Re: Allow equal after a short option
On Sun, Mar 09, 2008 at 12:42:37AM -0500, Jeff Johnson wrote:
> /bin/echo on my system is unmodified from
> Fedora 9 coreutils-6.10-4.fc9.i386
Interesting. So, what do you get with a manual run?
/bin/echo --foo --bar
/bin/echo -- --foo --bar
I see all the option information output literally, including the --.
What do you get if you try a "make check" using that perl -e patch
instead of echo? Does it still succeed for you?
> I added the longArg = NULL, am seeing the same failure on test # 9.
Very weird. I don't see how my change could affect a short option's
separated arg. Attached is an even safer version of the change that
ensures that the only time it ever sets longArg to NULL is if the
longArg was set to oe + 1 upon finding an equal sign.
I also tried using valgrind in the test suite:
result=`valgrind $builddir/$prog $*`
and the test-run didn't turn up any errors.
..wayne..
--- popt.c 9 Mar 2008 06:01:05 - 1.118
+++ popt.c 9 Mar 2008 14:03:00 -
@@ -883,6 +883,8 @@ int poptGetNextOpt(poptContext con)
optStringLen = (size_t)(oe - optString);
if (*oe == '=')
longArg = oe + 1;
+ else
+ oe = NULL;
/* XXX aliases with arg substitution need "--alias=arg" */
if (handleAlias(con, optString, optStringLen, '\0', longArg)) {
@@ -895,13 +897,16 @@ int poptGetNextOpt(poptContext con)
opt = findOption(con->options, optString, optStringLen, '\0',
&cb, &cbData,
singleDash);
- if (!opt && !singleDash)
- return POPT_ERROR_BADOPT;
+ if (!opt) {
+ if (!singleDash)
+ return POPT_ERROR_BADOPT;
+ if (oe)
+ longArg = NULL;
+ }
}
if (!opt) {
con->os->nextCharArg = origOptString + 1;
- longArg = NULL;
} else {
if (con->os == con->optionStack && F_ISSET(opt, STRIP))
{
Re: Allow equal after a short option
On Mar 8, 2008, at 11:24 PM, Wayne Davison wrote: On Sat, Mar 08, 2008 at 06:11:09PM -0500, Jeff Johnson wrote: Hmmm, we appear to have different behavior wrto echo. Your patch changes testit.sh to include an explicit "--", which (when I last fixed testit.sh like 3 weeks ago) does not appear in the output I am (and was) seeing. I tried it on Ubuntu 7.10 and CentOS 5 with the same result, so it's obviously a difference between whatever version of "echo" you have and the one in the gnu coreutils package. I'll attach a patch that makes the code use a simple perl -e construct to accomplish the same thing in a compatible manner (for any system with perl). Using that avoids the need to add the "--" chars to the output like I did in my earlier patch. While I believe you, I need to pass "make check" before releasing popt-1.14 or enabling your patch. /bin/echo on my system is unmodified from Fedora 9 coreutils-6.10-4.fc9.i386, verified with rpm -Vf /bin/echo. Claiming "obviously" explains nothing. And I'd rather understand the problem than band-aid with perl. Using perl in a popt "make check" adds a difficult build prerequsite as well. popt needs to handle "--" like any other CLI argument. I have added the tests and the 1 liner to have -c=foo functionality, just commented out and disabled for now. Please note that that one-line fix won't work without my prior patch that fixes the problem with a short option that has an embedded (or leading) equal in an abutting arg (e.g. "test1 -2foo=bar"). I'll attach it here in case you missed it. I added the longArg = NULL, am seeing the same failure on test # 9. If I skip test #9, there's several other tests that fail. The one element that changes is enabling/disabling your patch. And its not just /bin/echo that breaks. Here is rpm behavior with your -c=foo 1-liner enabled: [EMAIL PROTECTED] popt]$ rpm -q coreutils coreutils rpm: -q: unknown option Reverting the change, rebuilding, installing, I get this behavior instead: $ rpm -q coreutils coreutils-6.10-4.fc9.i386 So there's something not correct with your patch ... 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: Allow equal after a short option
On Sat, Mar 08, 2008 at 06:11:09PM -0500, Jeff Johnson wrote:
> Hmmm, we appear to have different behavior wrto echo. Your
> patch changes testit.sh to include an explicit "--", which (when
> I last fixed testit.sh like 3 weeks ago) does not appear in the
> output I am (and was) seeing.
I tried it on Ubuntu 7.10 and CentOS 5 with the same result, so it's
obviously a difference between whatever version of "echo" you have and
the one in the gnu coreutils package. I'll attach a patch that makes
the code use a simple perl -e construct to accomplish the same thing in
a compatible manner (for any system with perl). Using that avoids the
need to add the "--" chars to the output like I did in my earlier patch.
> I have added the tests and the 1 liner to have -c=foo functionality,
> just commented out and disabled for now.
Please note that that one-line fix won't work without my prior patch
that fixes the problem with a short option that has an embedded (or
leading) equal in an abutting arg (e.g. "test1 -2foo=bar"). I'll attach
it here in case you missed it.
..wayne..
--- test-poptrc 16 Feb 2008 22:16:10 - 1.4
+++ test-poptrc 9 Mar 2008 04:13:55 -
@@ -7,6 +7,6 @@ test1 alias -O --arg1
test1 alias --grab --arg2 "'foo !#:+'"
test1 alias --grabbar --grab bar
-test1 exec --echo-args echo --
+test1 exec --echo-args perl -e 'print "@ARGV"' --
test1 alias -e --echo-args
-test1 exec -a /bin/echo --
+test1 exec -a perl -e 'print "@ARGV"' --
--- popt.c 8 Mar 2008 17:26:30 - 1.116
+++ popt.c 8 Mar 2008 20:48:43 -
@@ -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))
{
Re: Allow equal after a short option
On Mar 8, 2008, at 12:56 PM, Wayne Davison wrote: On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote: Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1: 0 arg2: foo" I'm not seeing that error with the CVS version. I do note that my prior patch to fix the longArg pointer (e.g. "./test1 -2foo=bar") isn't there, but even commenting out that fix doesn't get test 9 to fail for me. I did see failures for tests 19-23 due to the --echo-args macro now outputting an extra "--" at the start. The attached patch fixes this, and also adds two new tests to check that the changed equal-handling works right. Hmmm, we appear to have different behavior wrto echo. Your patch changes testit.sh to include an explicit "--", which (when I last fixed testit.sh like 3 weeks ago) does not appear in the output I am (and was) seeing. I need a functional testit.sh, so I'm gonna wait for popt-1.14 release before wrestling further with the contextual problems of --echo-args behavior. I have added the tests and the 1 liner to have -c=foo functionality, just commented out and disabled for now. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: Allow equal after a short option
On Mar 8, 2008, at 12:56 PM, Wayne Davison wrote: On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote: Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1: 0 arg2: foo" I'm not seeing that error with the CVS version. I do note that my prior patch to fix the longArg pointer (e.g. "./test1 -2foo=bar") isn't there, but even commenting out that fix doesn't get test 9 to fail for me. I did see failures for tests 19-23 due to the --echo-args macro now outputting an extra "--" at the start. The attached patch fixes this, and also adds two new tests to check that the changed equal-handling works right. Those tests were run from a freshly built CVS from HEAD. But perhaps I've tricked myself somehow. Lemme study a bit while merging in this patch. Hmmm, I was seeing exactly the opposite, --echo-args was failing until I added the "--" argument separator a couple of weeks ago. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: Allow equal after a short option
On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote: > Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1: > 0 arg2: foo" I'm not seeing that error with the CVS version. I do note that my prior patch to fix the longArg pointer (e.g. "./test1 -2foo=bar") isn't there, but even commenting out that fix doesn't get test 9 to fail for me. I did see failures for tests 19-23 due to the --echo-args macro now outputting an extra "--" at the start. The attached patch fixes this, and also adds two new tests to check that the changed equal-handling works right. ..wayne.. popt-tests.sh Description: Bourne shell script
Re: Allow equal after a short option
On Mar 8, 2008, at 12:02 PM, Wayne Davison wrote: I think it would be nice to allow an equal to separate a short option letter from its abutting argument. e.g. these commands using the test1 executable would all work the same: ./test1 -2 foo ./test1 -2=foo ./test1 -2foo ./test1 --arg2 foo ./test1 --arg2=foo Since this has been a syntax error in released versions of popt, this should not cause a compatibility problem. This fix requires my prior patch to make sure that short-option parsing doesn't have longArg set. I think the patch is a reasonable extension, but there's more to do: [EMAIL PROTECTED] popt]$ make check ... make check-TESTS make[2]: Entering directory `/X/src/popt' Running tests in /X/src/popt Running test test1 - 1. Running test test1 - 2. Running test test1 - 3. Running test test1 - 4. Running test test1 - 5. Running test test1 - 6. Running test test1 - 7. Running test test1 - 8. Running test test1 - 9. Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1: 0 arg2: foo" Would you mind looking at the problem? Thanks ... 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List [email protected]
