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

There's a lot of pain out there, just google (rake.rb "failed with status").

I originally ran into this problem while using rake 0.8.7 in ruby 1.9.2 with rails 3.0.7. I thought it was a problem with cucumber, but that's how it's designed. Cucumber is doing the right thing and returning an error code, but rake is dumping unrelated backtrace information instead of simply reporting the error.
https://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/680
http://stackoverflow.com/questions/5053566/how-do-i-suppress-the-huge-stack-trace-after-a-rake-testtask-failure

Made this into a real patch file.

Instructions:

  $ cd /local/ruby-1.9.2-p180
  $ wget https://gist.github.com/raw/1003628/rake.patch
  $ patch -p1 < rake.patch

Can you provide a test case, or an example demonstrating the issue. I don't get a stack trace when I have a failing shell command.

Sure, no problem. See the Rakefile above which exhibits the problem on linux (ubuntu 10.10) given the following environment:

$ which ruby
/local/ruby-1.9.2-p180/bin/ruby
$ ruby -v
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]
$ which rake
/local/ruby-1.9.2-p180/bin/rake
$ rake -V
rake, version 0.8.7
$ gem list rake

*** LOCAL GEMS ***

rake (0.9.1, 0.9.0, 0.8.7)

I built ruby from the source here: http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p180.tar.gz
I don't think there is any platform/build dependent code in play here, but let me know if that Rakefile doesn't reproduce the problem.

The Rakefile produces the following output on my system when run:

$ rake
(in /tmp)
exit 1
rake aborted!
Command failed with status (127): [exit 1...]
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:993:in `block in sh'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:1008:in `call'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:1008:in `sh'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:1092:in `sh'
/tmp/Rakefile:3:in `block in <top (required)>'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:634:in `call'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:634:in `block in execute'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:629:in `each'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:629:in `execute'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:595:in `block in invoke_with_call_chain'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:588:in `invoke_with_call_chain'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:581:in `invoke'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2041:in `invoke_task'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2019:in `block (2 levels) in top_level'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2019:in `each'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2019:in `block in top_level'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2058:in `standard_exception_handling'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2013:in `top_level'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:1992:in `run'
/local/ruby-1.9.2-p180/bin/rake:31:in `<main>'

After the patch is applied, output from the same rakefile is:

$ rake
(in /tmp)
exit 1
rake aborted!
Command failed with status (127): [exit 1...]

put a link to this in the issues list for better tracking: jimweirich/rake#45

With the Rakefile:

task :default do
  sh('exit 1')
end

I get the following for Rake 0.8.7:

$ rake _0.8.7_
(in /Users/jim/pgm/rake/stack)
exit 1
rake aborted!
Command failed with status (127): [exit 1...]
/Users/jim/pgm/rake/stack/Rakefile:2
(See full trace by running task with --trace)

And the following for Rake 0.9.1:

$ rake _0.9.1_
exit 1
rake aborted!
Command failed with status (127): [exit 1...]

Tasks: TOP => default
(See full trace by running task with --trace)

I'm still not seeing the problem. Can anyone else verify the behavior?

Interesting. Can you show me the output from this on your system?

$ rake             # from an empty dir
rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2367:in `raw_load_rakefile'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2007:in `block in load_rakefile'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2058:in `standard_exception_handling'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2006:in `load_rakefile'
/local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:1991:in `run'
/local/ruby-1.9.2-p180/bin/rake:31:in `<main>'

Then using the path from that trace as follows:

$ cat /local/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb | sed '993!d'
       ok or fail "Command failed with status (#{status.exitstatus}): [#{show_command}]"

I looked on a friend's mac at work and we could reproduce the problem using --trace... so now I need to figure out where and how this option is being set on my system.

Trying to disable this with Rake.application.options.trace = false in the rakefile didn't change the behavior.

Testing on 2 macs and 1 unix machine has yielded slight different results for each environment. Is there a way we can normalize this for testing? Some systems pick up the gem rake, others pick up rvm, others pick up Mac's default rake... it's kind of a configuration nightmare. Maybe rake should be replaced in ruby/bin on gem install or maybe it shouldn't be there, but rather in gems/bin or something? Have to run, will look more later on my Mac at home.

Run

   gem | grep EXECUTABLE

That will tell you the directory that contains the Ruby executable and the ruby default rake command. It will also tell you the directory where the gem command installs the executables for installed gem. If you want installed gem command to override the default ruby ones (which is what you want if you are installing rake as gem), then just make sure the gem bin directory precedes the ruby bin directory in the $PATH environment.

I assume you meant "gem environment"... here it is for ubuntu:

lkyrala@oasis:/tmp/foo$ echo $PATH
/local/ruby-1.9.2-p180/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
lkyrala@oasis:~$ gem environment | grep EXECUTABLE
  - RUBY EXECUTABLE: /local/ruby-1.9.2-p180/bin/ruby
  - EXECUTABLE DIRECTORY: /local/ruby-1.9.2-p180/gems/bin
lkyrala@oasis:/tmp/foo$ rake -V
rake, version 0.8.7

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:

lkyrala@oasis:/tmp/foo$ echo $PATH
/local/ruby-1.9.2-p180/gems/bin:/local/ruby-1.9.2-p180/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
lkyrala@oasis:/local/ruby-1.9.2-p180/gems/bin$ gem environment | grep EXECUTABLE
  - RUBY EXECUTABLE: /local/ruby-1.9.2-p180/bin/ruby
  - EXECUTABLE DIRECTORY: /local/ruby-1.9.2-p180/gems/bin
lkyrala@oasis:/tmp/foo$ rake -V
rake, version 0.9.1

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:

/local/ruby-1.9.2-p180$ for file in $( find . -type f -name "rake" ); do echo `$file -V`: $file; done;
rake, version 0.8.7: ./bin/rake
rake, version 0.9.1: ./gems/bin/rake
rake, version 0.8.7: ./gems/gems/rake-0.9.0/bin/rake
rake, version 0.8.7: ./gems/gems/rake-0.9.1/bin/rake

---

Anyway, the problem still exists in rake-0.9.1 if you invoke with the --trace option:

lkyrala@oasis:/tmp/foo$ rake --trace
** Invoke default (first_time)
** Execute default
exit 1
rake aborted!
Command failed with status (127): [exit 1...]
/local/ruby-1.9.2-p180/gems/gems/rake-0.9.1/lib/rake/file_utils.rb:53:in `block in create_shell_runner'
/local/ruby-1.9.2-p180/gems/gems/rake-0.9.1/lib/rake/file_utils.rb:45:in `call'
/local/ruby-1.9.2-p180/gems/gems/rake-0.9.1/lib/rake/file_utils.rb:45:in `sh'
/local/ruby-1.9.2-p180/gems/gems/rake-0.9.1/lib/rake/file_utils_ext.rb:36:in `sh'
...

(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!

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.