Problem with grep -Fwf (version 2.5.1a-1 and 2.5.1a-2)

2006-07-28 Thread Daniel Einspanjer


Using the following files both of which had dos2unix run on them to be sure 
there were no line-ending issues:


= data.txt ===
abc
defghi
==

= filter.txt =
abc
deghi
==

These commands work as expected:
$ fgrep -f filter.txt data.txt
$ tail -1 data.txt | fgrep -wf filter.txt

But this command fails to return ghi:
$ fgrep -wf filter.txt data.txt
So it seems that after a match is discarded because it is not a full word 
(due to the -w flag), subsequent full word matches are also discarded.


I've tested this with the grep 2.5.1 installed on a recent Gentoo GNU/Linux 
machine and it behaves properly so I am guessing it might be a problem 
specific to the cygwin port.  I have not worked with Cygwin source yet, so 
I'm reporting the problem, and if I finish with the work tasks that surfaced 
the problem, I'll be happy to dig into the source and attempt to create a 
patch, but I'm hoping there might be someone out there that can quickly 
determine the problem and solution. :)

--
Daniel Einspanjer 




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Problem with grep -Fwf (version 2.5.1a-1 and 2.5.1a-2)

2006-07-28 Thread Daniel Einspanjer
I'm sorry, the message appeared to be formatted properly when I posted it 
but something must have happened during transmission.  Each file should have 
three lines. the data file has abc, def, and ghi.  The filter file has abc, 
de, and ghi.  The de line is significant to test the -w whole word matching 
flag.
I appreciate your looking at this and I'm sorry for the confusion.  Could 
you try it again with the files the way I just described and see if you 
might be able to reproduce the problem?


= data.txt =
abc
def
ghi
==
= filter.txt =
abc
de
ghi
==

Daniel

Christopher Faylor [EMAIL PROTECTED] wrote in 
message news:[EMAIL PROTECTED]

On Fri, Jul 28, 2006 at 01:53:32PM -0400, Daniel Einspanjer wrote:
Using the following files both of which had dos2unix run on them to be 
sure

there were no line-ending issues:

= data.txt ===
abc
defghi

  ^

==

= filter.txt =
abc
deghi
==

These commands work as expected:
$ fgrep -f filter.txt data.txt
$ tail -1 data.txt | fgrep -wf filter.txt

But this command fails to return ghi:
$ fgrep -wf filter.txt data.txt
So it seems that after a match is discarded because it is not a full word
(due to the -w flag), subsequent full word matches are also discarded.


Maybe it's a typo in your simplified test case but fgrep -w shouldn't 
match

defghi since the input is deghi.

I've tested this with the grep 2.5.1 installed on a recent Gentoo 
GNU/Linux

machine and it behaves properly so I am guessing it might be a problem
specific to the cygwin port.


I tried this test on Cygwin, Gentoo, and FC5 and got consistent results
on all.  If I remove the 'f' in defghi from data.txt then it also works
consistently on all three systems, i.e., it returns:

abc
deghi

cgf





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: Problem with grep -Fwf (version 2.5.1a-1 and 2.5.1a-2)

2006-07-28 Thread Daniel Einspanjer
Christopher Faylor [EMAIL PROTECTED] wrote in 
message news:[EMAIL PROTECTED]



Yes, I can reproduce it now and see that it goes away if I update the
grep sources with patches from the FC5 release.  I'll release a new
version of grep this weekend.

I wonder why every test case I tried worked.  I didn't think I had the
standard developer's blind spot for grep.

cgf



Meh! it seems that programs always have n + 1 edges so this is just another 
edge case.
I appreciate your persistence after my initial reporting goof and I'm glad 
to hear that a fix was easy to track down.


Thanks!

Daniel 




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Problem building setup.exe (zlib.h not found)

2005-04-17 Thread Daniel Einspanjer
I'm trying to build setup.exe from source.

I ran into the same problem mentioned by a thread back in 2003 where
using a windows cvs.exe instead of the cygwin one caused configure to
fail, and I made it past that, but now make is failing because it
can't find zlib.h.

This is the first cygwin based build I've ever tried before.  All my
other building has been msvc based.  I took all my msvc stuff out of
the environment, but I'm not sure how to go about trying to
troubleshoot why g++ can't find zlib.h (obviously, I double checked to
make sure the zlib package is installed).

Could someone give me some pointers here?


Re: Problem building setup.exe (zlib.h not found)

2005-04-17 Thread Daniel Einspanjer
Exactly what I needed to know.  Thanks muchly. :)

On 4/17/05, Brian Dessent [EMAIL PROTECTED] wrote:
 Daniel Einspanjer wrote:
 
  troubleshoot why g++ can't find zlib.h (obviously, I double checked to
  make sure the zlib package is installed).
 
 setup is a mingw program, you need mingw-zlib and mingw-bzip2.  (the
 source for these libraries used to be bundled, but if you're using a
 recent CVS checkout it now uses the system provided libraries from those
 packages.)
 
 Brian



Re: Problem building setup.exe (zlib.h not found)

2005-04-17 Thread Daniel Einspanjer
Max, sorry for not RTFMing closely enough.  I knew I had bz2 and zlib
libraries installed so I didn't click on the mingw prefix until Brian
highlighted it.

On 4/17/05, Daniel Einspanjer [EMAIL PROTECTED] wrote:
 Exactly what I needed to know.  Thanks muchly. :)
 
 On 4/17/05, Brian Dessent [EMAIL PROTECTED] wrote:
  Daniel Einspanjer wrote:
 
   troubleshoot why g++ can't find zlib.h (obviously, I double checked to
   make sure the zlib package is installed).
 
  setup is a mingw program, you need mingw-zlib and mingw-bzip2.  (the
  source for these libraries used to be bundled, but if you're using a
  recent CVS checkout it now uses the system provided libraries from those
  packages.)
 
  Brian