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

[Wolfgang Nádasi-donner]

Moin, moin!

There is a description for a method that does not exist presented by
"ri":
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>
Produced via OneClickInstaller 186-25 - ruby 1.8.6 (2007-03-13
patchlevel 0) [i386-mswin32]

Wolfgang Nádasi-Donner

 

[Tim Hunter]

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"

 

[John Joyce]

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

 

[Bertram Scharpf]

Hi,

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

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

 

[ChrisH]

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

 

[dblack]

Hi --

Hi,

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

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

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

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Bertram Scharpf]

Hi,

Am Dienstag, 14. Aug 2007, 22:40:58 +0900 schrieb (e-mail address removed):

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

 

[John Joyce]

Hi,

Am Dienstag, 14. Aug 2007, 22:40:58 +0900 schrieb (e-mail address removed):

I didn't mean it as harmful as it obviously sounds. Sorry,
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...

 

[Daniel Berger]

Moin, moin!

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


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>

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.

Regards,

Dan

 

[Bertram Scharpf]

Hi,

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

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

I was really hurt by your code.

Bertram

 

[John Joyce]

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.

Regards,

Dan

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

 

[John Joyce]

Hi,

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

I was really hurt by your code.

Bertram

Sorry Bertram!! I didn't mean to hurt you!
Maybe I was thinking of "Never Ending Story"

 

[Wolfgang Nádasi-donner]

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.

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

 

[Daniel Berger]

Booofff... - thank you for this information!

irb(main):001:0> require 'win32/dir'
=3D> true
irb(main):002:0> Dir::empty?('./')
=3D> 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

 

[Daniel Berger]

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

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

Regards,

Dan

 

[Phrogz]

On Aug 14, 11:33 am, "Wolfgang Nádasi-donner" <[email protected]>
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.

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?

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.

 

[James Britt]

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.)

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?

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

--
James Britt

"The use of anthropomorphic terminology when dealing with
computing systems is a symptom of professional immaturity."
- Edsger W. Dijkstra

 

[Eric Hodel]

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

 

[James Britt]

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 Davis et al) to fix RDoc and ri.


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


--
James Britt

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

 

[bbiker]

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

It does not seem to work on my system

C:\Documents and Settings\Owner>irb
irb(main):001:0> require 'win32/dir'
=> true
irb(main):002:0> Dir::empty?('./')
NoMethodError: undefined method `empty?' for Dir:Class
from (irb):2

using win32-dir version 0.3.2