FileUtils, a useful extension

i find these come in real handy, and thought they would be good for
inclusion into FileUtils or barring that, then maybe the guys at Facets
lib might be interested. they are based on Unix shell test options, i.e.
[ -d somedir ] etc.
it would be fairly trivial to implement the other test options as well.

module FileUtils

def b? path
File.blockdev? path
end

def c? path
File.chardev? path
end

def d? path
File.directory? path
end

def e? path
File.exists? path
end

def f? path
File.file? path
end

def x?
File.executable? path
end

end

def x? path
File.executable? path
end

of course

On Nov 30, 12:07 pm, Christophe M. [email protected]
wrote:

end
File.exists? path
end

def f? path
File.file? path
end

def x?
File.executable? path
end

Hmmm… you know about Kernel#test ? Eg.

test ?d, path

instead of

FileUtils.directory?(path)

$ ri Kernel#test


Kernel#test
test(int_cmd, file1 [, file2] ) => obj

  Uses the integer <em>aCmd</em> to perform various tests on
  <em>file1</em> (first table below) or on <em>file1</em> and
  <em>file2</em> (second table).

  File tests on a single file:

    Test   Returns   Meaning
     ?A  | Time    | Last access time for file1
     ?b  | boolean | True if file1 is a block device
     ?c  | boolean | True if file1 is a character device
     ?C  | Time    | Last change time for file1
     ?d  | boolean | True if file1 exists and is a directory
     ?e  | boolean | True if file1 exists
     ?f  | boolean | True if file1 exists and is a regular file
     ?g  | boolean | True if file1 has the \CF{setgid} bit
         |         | set (false under NT)
     ?G  | boolean | True if file1 exists and has a group
         |         | ownership equal to the caller's group
     ?k  | boolean | True if file1 exists and has the sticky bit

set
?l | boolean | True if file1 exists and is a symbolic link
?M | Time | Last modification time for file1
?o | boolean | True if file1 exists and is owned by
| | the caller’s effective uid
?O | boolean | True if file1 exists and is owned by
| | the caller’s real uid
?p | boolean | True if file1 exists and is a fifo
?r | boolean | True if file1 is readable by the effective
| | uid/gid of the caller
?R | boolean | True if file is readable by the real
| | uid/gid of the caller
?s | int/nil | If file1 has nonzero size, return the size,
| | otherwise return nil
?S | boolean | True if file1 exists and is a socket
?u | boolean | True if file1 has the setuid bit set
?w | boolean | True if file1 exists and is writable by
| | the effective uid/gid
?W | boolean | True if file1 exists and is writable by
| | the real uid/gid
?x | boolean | True if file1 exists and is executable by
| | the effective uid/gid
?X | boolean | True if file1 exists and is executable by
| | the real uid/gid
?z | boolean | True if file1 exists and has a zero length

 Tests that take two files:

     ?-  | boolean | True if file1 and file2 are identical
     ?=  | boolean | True if the modification times of file1
         |         | and file2 are equal
     ?<  | boolean | True if the modification time of file1
         |         | is prior to that of file2
     ?>  | boolean | True if the modification time of file1
         |         | is after that of file2

T.

On Nov 30, 2007, at 11:59 AM, Trans wrote:

it would be fairly trivial to implement the other test options as
end
File.file? path
instead of

?C | Time | Last change time for file1
?M | Time | Last modification time for file1
| | otherwise return nil
?z | boolean | True if file1 exists and has a zero length

T.

WOW!
I always found myself avoiding Kernel because its name reminds me of
the Linux Kernel, which I don’t want to delve into.
That’s amazing.
I’m almost shocked we’ve got so many file & directory tools when this
is there…

On Dec 1, 2007 2:59 AM, Trans [email protected] wrote:

def d? path

def x?
File.executable? path
end

Hmmm… you know about Kernel#test ? Eg.

test ?d, path

Anyone knows what happens with this in 1.9? AFAIK the ?d syntax is
going away… maybe symbols instead?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs