that’s pretty much the same like: system(‘rm -f fglrx*’) but I’m asking why one doesn’t allow regexpr into File.exists?
Probably because most people wouldn’t find it intuitive, there’s
already easy alternatives, and there doesn’t seem to be any desire for
it among the Ruby community in general. You’re the first person to
request it that I’ve seen.
From a development point of view, it’s not only more maintenance, but
also a slipperly slope towards having to review every other boolean
File method.
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.
On Wed, 5 Sep 2007 00:52:57 +0900
Daniel B. [email protected] 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.
Joel VanderWerf wrote the following on 04.09.2007 23:47 :
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)…
I agree that file matching via regular expressions is very convenient
in certain situations that are not handled by globs. You might want to
look at Rio (http://rio.rubyforge.org).
I would guess it is because file name pattern matching
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.