patch for rake in ruby-1.9.2-p180

rake.patch

--- a/lib/ruby/1.9.1/rake.rb	2011-06-01 20:36:01.000000000 -0400
+++ b/lib/ruby/1.9.1/rake.rb	2011-06-01 20:35:47.000000000 -0400
@@ -990,7 +990,7 @@
       show_command = show_command[0,42] + "..." unless $trace
       # TODO code application logic heref show_command.length > 45
       block = lambda { |ok, status|
-        ok or fail "Command failed with status (#{status.exitstatus}): [#{show_command}]"
+        ok or fail(RuntimeError, "Command failed with status (#{status.exitstatus}): [#{show_command}]", [])
       }
     end
     if RakeFileUtils.verbose_flag == :default

Rakefile

# testing rakefile
task :default do
  sh('exit 1')
end

Conclusions for future readers:

• Jim closed as non-reproduceable. He was not able to reproduce on 0.8.7 or 0.9.1 on a Mac system.
• I could reproduce on Ubuntu using a fresh build from source: http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p180.tar.gz which includes rake-0.8.7 by default (in bin/rake)
• rake-0.9.1
• I was able to reproduce in all versions of rake by using --trace, however Jim says that behavior is by design.

I found another response by Jim (assuming the same Jim) to this problem indicating that custom responses to sh errors can be handled by passing a block to sh. ( See http://muness.blogspot.com/2007/06/failing-rake-task-that-executes-shell_20.html ) So perhaps this is a cucumber problem after all?

Nevermind. In the time it's taken me to track this down the latest 'bundle update' / rake and cucumber now work together without throwing up. They don't call it the "bleeding edge" for nothing. :P

Thanks for posting the end result for posterity. Just ran into this on my 64-bit Archlinux install. I hadn't thought about it until I found this gist, but it's been a while since I updated rake and an update is just what the doctor ordered.