[#11073] segfault printing instruction sequence for iterator — <noreply@...>
Bugs item #10527, was opened at 2007-05-02 14:42
Hi,
On Thu, May 10, 2007 at 04:51:18PM +0900, Nobuyoshi Nakada wrote:
Hi,
Hi,
This seems to make valgrind much happier.
On Thu, May 17, 2007 at 11:14:35PM +0900, Paul Brannan wrote:
Hi,
Now 'a' shows up twice in the local table:
Hi,
[#11082] Understanding code: Kernel#require and blocks. — Hugh Sasse <hgs@...>
I'm trying to debug a Rails application which complains about an
On 5/4/07, Hugh Sasse <hgs@dmu.ac.uk> wrote:
On Fri, 4 May 2007, George wrote:
On Fri, May 04, 2007 at 06:18:19PM +0900, Hugh Sasse wrote:
[#11108] pattern for implementation-private constants? — David Flanagan <david@...>
Hi,
I believe there isn't a way, but I don't think it's really necessary. Just
[#11127] Bugs that can be closed — "Jano Svitok" <jan.svitok@...>
I propose closing these bugs as invalid:
[#11145] Rational comparison to 0 fails when denominator is != 1 — <noreply@...>
Bugs item #10739, was opened at 2007-05-10 22:06
Hi,
[#11169] Allow back reference with nest level in Oniguruma for Ruby again — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <wonado@...>
Remark: I posted this text in comp.lang.ruby first, but Matz told me,
Does it make sense or is it required to write this as a RCR?
[#11176] FileUtils.rm_rf misfeature? — johan556@...
Hi!
[#11210] Pathname ascend and descend inclusive parameter — TRANS <transfire@...>
I would like to suggest that Pathname#ascend and Pathname#descend
[#11234] Planning to release 1.8.6 errata — Urabe Shyouhei <shyouhei@...>
Hi all.
On 25/05/07, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
[#11252] Init_stack and ruby_init_stack fail to reinit stack (threads problem?) — <noreply@...>
Bugs item #11134, was opened at 2007-05-25 12:14
Hi,
Nobuyoshi Nakada wrote:
[#11255] ruby_1_8_6 build problem (make install-doc) — johan556@...
Hi!
[#11271] providing better support through rubyforge tracker categories — Ryan Davis <ryand-ruby@...>
I'm going to make more categories for the trackers (bugs and patches)
[#11367] BUG: next in lambda: 1.8.6 differs from 1.8.4 and 1.9.0 — David Flanagan <david@...>
A toplevel next statement in a lambda does not return a value in 1.8.6,
[#11368] $2000 USD Reward for help fixing Segmentation Fault in GC — Brent Roman <brent@...>
Hi Brent,
FileUtils.rm_rf misfeature?
Hi!
The methods in "fileutils" seem to be modeled after UNIX commands like
rm/mkdir/cd/... and sometimes with options added to the name (e.g.
"mkdir_p"). I guess this also means that the methods should work like
the corresponding UNIX commands.
But I think "rm_rf" behaves strange. The corresponding UNIX command
"rm -rf" has as a post condition that the files/directories given as
argument should be *nonexisting* after the command. Otherwise the exit
code will signal that the command failed. More specifically the
man-page says the following about the -f option (on OS-X):
-f Attempt to remove the files without prompting for confirma-
tion, regardless of the file's permissions. If the file does
not exist, do not display a diagnostic message or modify the
exit status to reflect an error. The -f option overrides any
previous -i options.
It does *not* say that the command totally ignores any errors. To
illustrate this, suppose I run the following commands:
$ mkdir -p test-dir1/dir2
$ touch test-dir1/dir2/file1
$ sudo chown nobody:nobody test-dir1/dir2
$ rm -rf test-dir1 ; echo $status
rm: cannot remove `test-dir1/dir2/file1': Permission denied
1
The exit is nonzero since the command failed to remove the directory
tree. I suppose this means that FileUtils.rm_rf should give an
exception in the same situation. But it doesn't.
Should this be considered a bug in FileUtils, or is there some reason
why FileUtils differ in behavior?
Below I give a Ruby unit-test that illustrates the current "misfeature".
/Johan Holmberg
#--------------------------------
# NOTE: script uses "sudo" and "rm -rf". I don't like putting such "strong"
# commands in test scripts, but used with caution it should not be dangerous.
# And this unit test is just for illustrating the "bug".
require "test/unit"
require "fileutils"
class TC_rm_rf < Test::Unit::TestCase
def test_failing_rm_rf
# setup tree that we will not be able to remove
ok = true
ok &&= system "sudo rm -rf test-dir1"
ok &&= system "mkdir -p test-dir1/dir2"
ok &&= system "touch test-dir1/dir2/file1"
ok &&= system "sudo chown nobody:nobody test-dir1/dir2"
assert(ok)
begin
FileUtils.rm_rf("test-dir1")
got_exception = false
rescue => e
got_exception = true
end
if got_exception
assert( File.exist?("test-dir1"),
"Exception so we should have failed to remove 'test-dir1'" )
else
assert( ! File.exist?("test-dir1"),
"'test-dir1' still exists, but we got no exception" )
end
end
end
#--------------------------------
Running the script above give the following error:
1) Failure:
test_failing_rm_rf(TC_rm_rf) [TC_rm_rf.rb:28]:
'test-dir1' still exists, but we got no exception.
<false> is not true.
1 tests, 2 assertions, 1 failures, 0 errors
#--------------------------------