gnu grep in windows

1025 views
Skip to first unread message

Mickey Ferguson

unread,
Mar 14, 2008, 1:01:47 PM3/14/08
to
I'm using the gnu grep utility (as ported from the latest - version 2.5.2 I
believe). With its -r switch, it has a limited recursive ability. However,
I've found that any filename pattern matching is case sensitive, which in
windows, it should not be. Does anyone know how to override this, or maybe
can point me to a grep that is fully gnu-compatible, with all of its latest
fixes and everything, while also fixing this filename case sensitivity
issue? Any help would be appreciated.

Here is a thread I had started in the gnu.utils.help/bug forum, which
eventually pointed me to windows-related groups.

"Mickey Ferguson" <ReneeMicke...@verizon.net> wrote in message
news:mailman.7839.12038206...@gnu.org...
> Bob, thanks for the help. You are right about the missing directory
> argument. I missed that earlier. By supplying ".", it eliminated the
> 'Not enough space' error. I finally got it to the point where I got it
> mostly working, but I discovered one thing about the port that may be good
> for the unix environment, but doesn't work for Windows: The filename
> pattern matching is case sensitive. In other words, if I had a file named
> "MyFile.txt" and I searched for "my*.txt" (without the quotes in both
> cases), it would fail to find it, while if I searched for "My*.txt" it
> would find it. I understand that in the unix world filenames are
> case-sensitive, but in the Windows world they are not. Thus, file pattern
> matching should not be case-sensitive for the Windows implementation.
>
> "Bob Proulx" <b...@proulx.com> wrote in message
> news:mailman.7817.120376077...@gnu.org...
>> Mickey Ferguson wrote:
>>> My problem is that it just doesn't work for me. (I'm using XP SP2.)
>>> When I use the -r switch, I get a 'Not enough space' error.
>>
>> That does seem strange.
>>
>>> ->grep -rl --include=*.ini Change
>>> grep: (standard input): Not enough space
>>
>> First things first. You are missing a directory argument in which to
>> recurse. Because grep does not have any file/directory arguments to
>> process it defaults to reading standard input. Using -r does not make
>> sense with regards to standard input.
>>
>> Fix this first by giving grep a directory to recurse into. When using
>> the -r option it is typical to use the '.' directory. Try this:
>>
>> grep -rl --include=*.ini Change .
>>
>>> I've created an alias in my command processor (4nt) language, that
>>
>> The typical way to do this would be to use 'find'.
>>
>> find . -name "*.ini" -exec grep -l Change {} +
>>
>> The {} is replaced by find with a maximum list of filenames and the
>> '+' terminates the command.
>>
>>> ... This works fine, but I'd rather figure out what I'm doing wrong
>>> above with the -r switch.
>>
>> Admirable. Looks like it is a bug in the port to me. It doesn't give
>> that error in GNU grep's native GNU environment. But your results
>> sound as if the code is trying to recurse on stdin and failing. That
>> should be reported to the Cygwin folks.
>>
>> Bob


Reply all
Reply to author
Forward
0 new messages