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