I did this during RailsConf, while browsing the routing source: http://dev.rubyonrails.org/ticket/5507
I showed it to Nicholas on IRC, and he wondered why it didn't just use Pathname#cleanpath from the standard library, rather than reinventing it. That seemed like a good question to me, so I rewrote normalize_paths to make use of that feature. This produced a test failure on MacOS and Win32. That struck me as fairly odd, and I investigated. It turns out that the canned test paths in the normalize_paths test are unrealistic. The windows test sets up test paths containing backslashes. However, this isn't what actually happens on a Windows system. Here's a sample of the actual load paths that get passed to normalize_paths on my Win32 box (many removed, for readability.): "./script/../config/../app/controllers/" "./script/../config/../app" "./script/../config/../components" "./script/../config/../config" "./script/../config/../lib" "./script/../config/../vendor" "./script/../config/../vendor/rails/railties" "./script/../config/../vendor/rails/railties/lib" "./script/../config/../vendor/rails/activesupport/lib/active_support/vendor" "c:/ruby/lib/ruby/site_ruby/1.8" "c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt" "c:/ruby/lib/ruby/1.8" "c:/ruby/lib/ruby/1.8/i386-mswin32" "." "./script/../config/../vendor/rails/railties/builtin/rails_info" The normalize_paths method has been written to deal with backslashes, and this is presumably why Pathname wasn't used. However, this doesn't actually seem to happen in Ruby. I thought I'd toss that out there before writing another patch. Changing the code and the tests for that code at the same time is slightly riskier, but I think is warranted here. Thanks, --Wilson. _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
