bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grep-dir test


From: Eric Blake
Subject: Re: grep-dir test
Date: Mon, 19 Dec 2011 13:34:32 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/19/2011 01:24 PM, Eli Zaretskii wrote:
>> Date: Mon, 19 Dec 2011 11:09:30 -0700
>> From: Eric Blake <address@hidden>
>> CC: address@hidden
>>
>> Gnulib is able to emulate fopen(".", "r") with sane semantics on mingw
>> (by opening the null device under the hood, so that any actual fread()
>> of the FILE* will return immediate EOF); but it looks like grep is not
>> using that gnulib module.
> 
> Thanks.  FWIW, it doesn't look like anyone cares about Grep working on
> Windows as a native program, because the simplest commands, something
> like "grep -R foo .", cause Grep to emit an error message and quit (I
> already fixed this in my sandbox).  But that's not due to the issue
> being discussed, and opening the null device won't help here.

Please post the patches you used in your sandbox, if you'd like them
incorporated upstream.

> 
> Anyway, opening the null device would simply emulate an empty file,
> which is why I asked what was the purpose of using a directory for the
> search pattern instead of using an empty file.

The gnulib module also takes care to replace things like fstat(), so
that if you query the properties of fileno(fopen(".","r")), you still
see the properties of the original directory, and not those of the null
device that was opened under the hood.  The intent of the test is that
grep should behave differently when operating on a directory instead of
a regular file.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]