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).
···
On Sep 4, 8:43 am, kazaam <kaz...@oleco.net> wrote:
Hi,
if I wanna check if a file exists like fglrx.i386.8.40.3.ko why is File.exists? not able to handle regexp to check this like:
system('rm fglrx*') if File.exists?(/^fglrx.+/)
--> ./test.rb:4:in `exists?': can't convert Regexp into String (TypeError)
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.
Regards,
Dan
···
On Sep 4, 10:00 am, kazaam <kaz...@oleco.net> wrote:
On Wed, 5 Sep 2007 00:52:57 +0900 > > Daniel Berger <djber...@gmail.com> wrote:
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.
Gary Wright
···
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?
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.
···
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:
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Joel VanderWerf wrote the following on 04.09.2007 23:47 :
Gary Wright 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)...
Lionel
···
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:
Joel VanderWerf wrote the following on 04.09.2007 23:47 :
Gary Wright 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.
···
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:
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407