incorrect return value of Pathname.realdirpath of Pathname objects created by Pathname.entries
It appears when calling realdirpath on a Pathname object returned by Pathname#entries, the returned value is always the current working directory of the ruby process, instead of the location of the file in the filesystem
This disagrees with the rdoc description of Pathname#realdirpath, which does state that realdirpath will return the absolute name of the file.
Tho following code demonstrates the issue:¶
ruby-1.9.3-p0 -ve "require 'pathname'; puts Pathname.new('/tmp/thing').entries.sort.realdirpath"¶
This is the output from the ruby process:¶
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
According to my interpretation of the description in rdoc, the correct output should be "/tmp/thing/a"
- ext/pathname/pathname.c (path_entries): add document suggested by the thread [Bug #5859].
#1 [ruby-core:41960] Updated by Motohiro KOSAKI about 4 years ago
A following modified script tell us why the script don't work as you expect. Pathname#entries return directly entrie, not absolute path. then, it forgot /tmp/thing.
% ./ruby--trunk -e "require 'pathname'; p Pathname.new('/tmp/thing').entries.sort"
It is not a bug. just misleading spec.
#2 [ruby-core:41961] Updated by Benoit Daloze about 4 years ago
I was going to answer but kosaki just did it.
Anyway, #entries always return filenames.
#children return what you would expect by default(with_directory=true):
ruby -e "require 'pathname'; puts Pathname.new('/tmp/thing').children.first.realdirpath" # => /tmp/thing/a
Although it would not work either if you used a relative path and chdir'd, in which case you should #expand_path before.
I think it would be worth to add an example to Pathname#entries and I'm unsure if such low-level method is useful at all in Pathname.
#4 Updated by Akira Tanaka about 4 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100