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

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.