From: Joel VanderWerf <vjoel@...>
Date: 2007-09-05T07:20:51+09:00
Subject: Re: Why does File.exists? not support regexp? It would be very handfull?

Lionel Bouton wrote:
> Joel VanderWerf wrote the following on 04.09.2007 23:47 :
>> Gary Wright wrote:
>>> On Sep 4, 2007, at 12:00 PM, kazaam wrote:
>>>> On Wed, 5 Sep 2007 00:52:57 +0900
>>>> Daniel Berger <djberg96@gmail.com> wrote:
>>>>
>>>>> Dir["fglrx*"].each{ |file| File.delete(file) }
>>>>>
>>>> that's pretty much the same like: system('rm -f fglrx*') but I'm
>>>> asking why one doesn't allow regexpr into File.exists?
>>> I would guess it is because file name pattern matching
>>> is subtly different from string pattern matching.  In
>>> particular you have the problem of directory hierarchies
>>> and how to handle the separator character (typically '/').
>>> The common file pattern syntax is also *not* the same
>>> as general regular expressions.
>> The slocate(1) program does have a -r option for searching file paths
>> with a regex, so there is some precedent.
>>
> slocate uses it's own database, not direct file access. File.exists?
> uses a system call directly. Using regexes would need to list all files
> that could match (a directory or the whole virtual filesystem depending
> on what you are matching with: a filename in a given directory or a
> path). This is far from a common need and in the general case far too
> slow: developpers are better off coding the regex matching code
> themselves and optimize it by listing the smallest subset of filepaths
> the OS can give them before they filter with a regex (which is trivial
> to do in Ruby anyway)...

Well, there's "find -regex", too, but I agree that regex matching is 
probably better for narrowing down a globbed search.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407