-
-
Save coldnebo/1003628 to your computer and use it in GitHub Desktop.
--- 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 |
# testing rakefile | |
task :default do | |
sh('exit 1') | |
end |
clarified the previous comment.
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.
I assume you meant "gem environment"... here it is for ubuntu:
Odd, that isn't what I expected... I thought the executable directory would somehow be the same as the ruby exec dir.
Indeed, I did not have gem/bin before bin in my path, so I set that correctly:
Ok, freakin' weird... same gem environment reported, but different rake version!!
Turns out there is some unexpected weirdness in terms of stale versions of rake packaged with the various gems:
Anyway, the problem still exists in rake-0.9.1 if you invoke with the --trace option:
(Notice that this stacktrace is misleading because it is not rake's fault that the shell script 'exit 1' returned a non-zero exit code.)
Hope this helps!