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:

[jbj@wellfleet 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