Non Existent Method Dir.empty? Description via "ri"

Moin, moin!

There is a description for a method that does not exist presented by
“ri”:

Console Protocol >>>>>
C:\Dokumente und Einstellungen\wolfgang>ri Dir.empty?
------------------------------------------------------------ Dir::empty?
Dir::empty?(path)


 Returns whether or not +path+ is empty. Returns false if +path+ is
 not a directory, or contains any files other than '.' or '..'.

C:\Dokumente und Einstellungen\wolfgang>irb
irb(main):001:0> Dir::empty?(’./’)
NoMethodError: undefined method `empty?’ for Dir:Class
from (irb):1
irb(main):002:0>

EOCP >>>>>

Produced via OneClickInstaller 186-25 - ruby 1.8.6 (2007-03-13
patchlevel 0) [i386-mswin32]

Wolfgang Nádasi-Donner

Interesting. This is from Ruby 1.8.6 on OS X. I’ve got a pretty vanilla
install, no gems.

timothyhunter$ ri Dir::empty?
Nothing known about Dir::empty?
timothyhunter$ ruby -e “p RUBY_VERSION”
“1.8.6”

I’ve got Ruby 1.8.4 on OSX with many gems installed.
When I do
ri empty

I get this:

More than one method matched your request. You can refine
your search by asking for information on one of:

  Array#empty?, Hash#empty?, Queue#empty?, Set#empty?,

String#empty?,
StringScanner#empty?, ThreadsWait#empty?

Looks like you’ve confused a method from another class.

You might want to use something like this:

def dir_empty?(path_to_dir)
Dir.chdir(path_to_dir)
if Dir.glob(’*’).length > 0
return false
else
return true
end

Hi,

Am Dienstag, 14. Aug 2007, 21:58:17 +0900 schrieb John J.:

You might want to use something like this:

def dir_empty?(path_to_dir)
Dir.chdir(path_to_dir)
if Dir.glob(’*’).length > 0
return false
else
return true
end

What’s this?

  1. ‘end’ is missing.
  2. ‘if … then false else true end’ is a lot of hot air
    around ‘not …’.
  3. As a side effect the method changes the current
    directory.

Say

def dir_empty? path_to_dir
Dir.chdir path_to_dir do
not Dir.glob(’*’).length > 0
end
end

Then, you may consider hidden files …

First think, then write. Sorry!

Bertram

On Aug 14, 9:08 am, Bertram S. [email protected] wrote:
snip

First think, then write. Sorry!

Bertram

A little more thought and a review of Ruby-doc shows that it could be
as simple as:
Class Dir
def empty?(path=Dir.pwd)
Dir.entries(path).empty?
end
end

cheers
Chris

Hi,

Am Dienstag, 14. Aug 2007, 22:40:58 +0900 schrieb [email protected]:

On Tue, 14 Aug 2007, Bertram S. wrote:

First think, then write. Sorry!

Please leave the snideness and nastiness out of it. They add nothing
but snideness and nastiness.

I didn’t mean it as harmful as it obviously sounds. Sorry,
again.

Bertram

On Aug 14, 2007, at 9:24 AM, Bertram S. wrote:

again.
Then take your own advice about thinking first and then writing, friend.
No offense taken, I know I’m not the only one who writes something
and posts quickly because there are other things to do.
I wasn’t trying to give a 100% perfect solution, just a quick example
idea of what could be done.
Lack of the end token would be caught by the interpreter and the OP
would notice or learn from it anyway.
everybody forgets an end here and there.
As for hidden files, well that’s somebody else’s problem, isn’t it?
Depending on point of view, a directory only containing hidden files
could be considered empty!
So whether or not those files are important depends on the program’s
needs.
In that case, hidden or not should be an optional argument with a
default.

That said, though we really have to ask what is meant by empty?
Directories on many platforms contain hidden files or hidden
symlinks. I think that calls for more than one method definition to
handle those respective distinctions.
hidden_files_in_dir?(path_to_dir)
symlinks_in_dir?(path_to_dir)

As is often the case, d.a.b. has the most concise solution…

Hi –

On Tue, 14 Aug 2007, Bertram S. wrote:

return true
Say

def dir_empty? path_to_dir
Dir.chdir path_to_dir do
not Dir.glob(’*’).length > 0
end
end

How about:

def dir_empty?(path_to_dir)
Dir.glob("#{path_to_dir}/*").empty?
end

Then, you may consider hidden files …

First think, then write. Sorry!

Please leave the snideness and nastiness out of it. They add nothing
but snideness and nastiness.

David

On Aug 12, 3:01 pm, “Wolfgang Nádasi-donner” [email protected]
wrote:


 Returns whether or not +path+ is empty. Returns false if +path+ is
 not a directory, or contains any files other than '.' or '..'.

C:\Dokumente und Einstellungen\wolfgang>irb
irb(main):001:0> Dir::empty?(’./’)
NoMethodError: undefined method `empty?’ for Dir:Class
from (irb):1
irb(main):002:0>

You’re picking up Dir.empty? from win32-dir, which ships with the one-
click installer. In order to use it, you have to require it first. :slight_smile:

Regards,

Dan

Hi,

Am Mittwoch, 15. Aug 2007, 00:15:25 +0900 schrieb John J.:

again.
Then take your own advice about thinking first and then writing, friend.

I was really hurt by your code.

Bertram

You’re picking up Dir.empty? from win32-dir, which ships with the one-
click installer. In order to use it, you have to require it first. :slight_smile:

Regards,

Dan

So it kind of exists?
Oh no, platform dependent Ruby…

Daniel B. wrote:

On Aug 12, 3:01 pm, “Wolfgang N�dasi-donner” [email protected]
wrote:


 Returns whether or not +path+ is empty. Returns false if +path+ is
 not a directory, or contains any files other than '.' or '..'.

C:\Dokumente und Einstellungen\wolfgang>irb
irb(main):001:0> Dir::empty?(’./’)
NoMethodError: undefined method `empty?’ for Dir:Class
from (irb):1
irb(main):002:0>

You’re picking up Dir.empty? from win32-dir, which ships with the one-
click installer. In order to use it, you have to require it first. :slight_smile:

Booofff… - thank you for this information!

irb(main):001:0> require ‘win32/dir’
=> true
irb(main):002:0> Dir::empty?(’./’)
=> false

Unfortunately it is not visible in the ri output where the method comes
from.

Wolfgang Nádasi-Donner

On Aug 14, 2007, at 11:17 AM, Bertram S. wrote:

Please leave the snideness and nastiness out of it. They add
Bertram

Sorry Bertram!! I didn’t mean to hurt you!
Maybe I was thinking of “Never Ending Story”

On Aug 14, 11:33 am, “Wolfgang Nádasi-donner” [email protected]
wrote:

    from (irb):1

=> false

Unfortunately it is not visible in the ri output where the method comes
from.

That’s an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven’t double checked the ri options, but I
don’t think there’s a way.

If not, we should probably discuss (here or on ruby-core) if it’s
feasible and, if so, what the output should look like.

Or, we could collectively decide that, when modifying core classes, we
should stick a tag of some sort on the method doc itself, either so
that it shows up literally in the output, or something rdoc can latch
onto. For example, the actual comments look like this:

Returns whether or not +path+ is empty. Returns false if +path+

is not a directory, or contains any files other than ‘.’ or ‘…’.

def self.empty?(path)

end

Perhaps I should add this at the bottom of each comment?

library: win32-dir

Dunno. What do people think?

Regards,

Dan

On Aug 14, 11:54 am, Daniel B. [email protected] wrote:

On Aug 14, 11:33 am, “Wolfgang Nádasi-donner” [email protected]
wrote:

end

Perhaps I should add this at the bottom of each comment?

library: win32-dir

Dunno. What do people think?

I think that’s a hack solution to the problem. It might be a good idea
since getting rdoc/ri fixed will take a lot of time, but the proper
solution is as you say: We need rdoc and ri to be fixed to properly
note what file/library a method was defined (and redefined) in.

I’m not (yet) volunteering to do any of the spec or implementation
work for this, but I’m on the verge. Proper documentation is a near
passion of mine, and although my latest solution (years old now -
http://phrogz.net/ObjJob/) doesn’t address this particular concern, I
would love to see and/or do some serious work to make auto-generated
documentation:

  • Include information on what file you need to add
  • Optionally show/hide inherited methods
  • Optionally list ‘attributes’ among methods
  • Handle method redefinitions, including documentation from both.

I’m quite disturbed that (last time I checked)
http://www.ruby-doc.org/core
includes classes modules and methods from stdlib. Clearly that
shouldn’t be the case (right), and is related to this.

On Aug 14, 10:35 am, John J. [email protected]
wrote:

You’re picking up Dir.empty? from win32-dir, which ships with the one-
click installer. In order to use it, you have to require it first. :slight_smile:

Regards,

Dan

So it kind of exists?
Oh no, platform dependent Ruby…

Bad news - many of the current core methods are platform dependent.

Regards,

Dan

Daniel B. wrote:

That’s an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven’t double checked the ri options, but I
don’t think there’s a way.

If not, we should probably discuss (here or on ruby-core) if it’s
feasible and, if so, what the output should look like.

I believe this is a known problem. (Known, at least, on the ruby-doc
list, and I think discussed on ruby-talk before)

Assorted libraries that ship with Ruby and alter core classes (for
example, Yaml) end up having their methods listed with the default
methods of core classes (for example, look at the rdocs for Array; it
lists ‘to_yaml’ as a method.)

end

Perhaps I should add this at the bottom of each comment?

library: win32-dir

Dunno. What do people think?

It may be a reasonable quick fix, though long term ri and rdoc need to
be re-written to stop producing broken docs.


James B.

“The use of anthropomorphic terminology when dealing with
computing systems is a symptom of professional immaturity.”

  • Edsger W. Dijkstra

On Aug 14, 2007, at 10:54, Daniel B. wrote:

from.

That’s an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven’t double checked the ri options, but I
don’t think there’s a way.

ri --system

$ ri Rake::Task -f simple
Class: Rake::Task
[…]
$ ri --system Rake::Task -f simple
Nothing known about Rake::Task

Phrogz wrote:

I’m quite disturbed that (last time I checked) http://www.ruby-doc.org/core
includes classes modules and methods from stdlib. Clearly that
shouldn’t be the case (right), and is related to this.

Quite true. Every so often people write to me to complain/inquire about
that; I don’t have a good response other than, “That’s how RDoc was
written.” And I don’t know of a good, automated solution to fixing that
on ruby-doc so that the generated docs make more sense.

I’ve wondered if custom .document files might help, but have not found
time to experiment.

Another question I get is, “Why are there two places to look for API
docs, instead of a single RDoc path where each class or lib page simply
tells you what you need to use it?”

Ruby Central has in the past offered funding to people or groups for
writing this or that cool or interesting code. I’d like to see that $$
offered to people (i.e. Ryan D. et al) to fix RDoc and ri.

It’s a non-trivial task but well worth community funding.


James B.

www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.risingtidesoftware.com - Wicked Cool Coding

Eric H. wrote:

On Aug 14, 2007, at 10:54, Daniel B. wrote:

from.

That’s an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven’t double checked the ri options, but I
don’t think there’s a way.

ri --system

$ ri Rake::Task -f simple
Class: Rake::Task
[…]
$ ri --system Rake::Task -f simple
Nothing known about Rake::Task

It helps in this case, but if some parts of the standard library change
core classes, the changes are still listed - example: “ri --system
Array” lists yaml stuff.

Wolfgang Nádasi-Donner

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