Skip to content
This repository

Rails projects do not work if project path contains open bracket "[" #6010

Closed
DreadPirateShawn opened this Issue · 33 comments

10 participants

Shawn Falkner-Horine Andrew White Steve Klabnik Larz Conwell Jeremy Walker Aaron Patterson Piotr Sarnacki Richard Schneeman Eric Hodel Konstantin Haase
Shawn Falkner-Horine

Rails projects do not function if they are created within a project path that contains an open bracket "[".

Repro:

I created the following folders:

/coding/workspace/test1
/coding/workspace/test 2
/coding/workspace/test [3]
/coding/workspace/test [4
/coding/workspace/test ]5
/coding/workspace/test [6/subfolder

Within each of them, I created a new Rails project using "rails new hello_world". I then cd'ed into the hello_world project folder and ran "rails server". Lastly I loaded http://localhost:3000/ in a web browser.

Rails projects within folders 1,2,5 work just fine (they display "public/index.html"), while Rails projects within folders 3,4,6 do not work. Specifically, they return the following error instead of displaying the smoke test "public/index.html":

Routing Error

No route matches [GET] "/"
Try running rake routes for more information on available routes.

I have confirmed that the projects are created correctly, by diff'ing a working and non-working project:

$ diff -r */hello_world
diff -r test [4/hello_world/config/initializers/secret_token.rb test1/hello_world/config/initializers/secret_token.rb
7c7
< HelloWorld::Application.config.secret_token = 'e84be29ba3ae3fc8a69f44b66e03070e0ef7fbd329816d7dd8ba7f9c0b0bd637480370794a1acf58eed4eda9dd92ca67a1f7784d54241d4b0dfb1a8011c0c3a2'
---
> HelloWorld::Application.config.secret_token = 'f09e0ad716dd67a1a2d5acd1ff6765d5dcaaf9d3c5974c708a46b31486cd31b1a6e94e9a0ec55a0941c2e560d26cdaac835f113edb3eb5062a5b9d05d0ef66cf'

Lastly, I have reproduced this on Mac OS X 10.7.3 (ruby 1.8.7, gem 1.3.6, Rails 3.2.3) and Linux Mint (ruby 1.9.3p194, gem 1.8.23, Rails 3.2.3).

Shawn Falkner-Horine

Note: Also referenced on StackOverflow, where I filed the issues with Rails before I realized why the "hello world" tutorials weren't working. http://stackoverflow.com/questions/10292645/ruby-on-rails-hello-world/10328952

Larz Conwell

This is quite weird, though I don't see it being that effective to change. Why not just rename the directory?

Shawn Falkner-Horine

I have a much larger project system using a naming convention that involves square brackets, and would like to incorporate Rails without having to revamp my entire file system. I'm not saying I'm a common use-case, but Rails should function properly within any directory path which uses legitimate characters on a Unix file system.

More frustrating is the lack of clear feedback -- up until actually loading "localhost:3000", everything appears to be functioning properly. Then an error is thrown, which gives no indication about the actual problem. It may be an infrequent situation, but it's guaranteed to reproduce on both Unix and Mac OS X if any "[" is in the directory path, with no indication to the user why the most basic Rails deployment is failing completely.

After spending about 12 hours on the most basic Rails deployment ('hello_world') and almost abandoning Rails altogether, and then filing a clear defect with detailed repro on both Linux and Mac OS X, I confess it's a bit disheartening that the response is to suggest that I rename my directory. Given the bug, that's definitely my only option at the moment.

But the defect remains, and the effect is pretty drastic on anyone who stumbles into it by accident. Seems unwise to leave this issue in the Rails code, long-term.

Larz Conwell

I'm gonna see if I can reproduce the problem and I'll work from there.

What version of rails are you using? 3.2.* I presume? Or are you using head?

I was just suggesting the easiest solution, I shouldn't of assumed the availability of renaming the directories, I'm sorry.

Shawn Falkner-Horine

No worries -- mostly I was worried at first that you were suggesting a reason the bug didn't need to be fixed. If that's not the case, then I rescind my defensiveness and instead I thank you for the help.

As for versions, I've reproduced this on Mac OS X 10.7.3 (ruby 1.8.7, gem 1.3.6, Rails 3.2.3) and Linux Mint (ruby 1.9.3p194, gem 1.8.23, Rails 3.2.3).

Larz Conwell

Okay I'm getting the same error, using a parent directory name called test [3]

When trying to display a root route root :to => "post#index" in config/routes.rb

Template is missing

Missing template post/index, application/index with {:locale=>[:en], :formats=>[:html], :handlers=>[:erb, :builder, :coffee]}. Searched in: * "/home/larz/Desktop/test [3]/hey/app/views"

When no root route is used in routes.rb, which displays the default public/index.html page

Routing Error
No route matches [GET] "/"
Try running rake routes for more information on available routes.

I don't think this is rails specific but the way OS's handle directory names. In Linux to create the test [3] directory I had to do mkdir 'test [3]' and to cd into the directory I had to do cd test\ \[3\] to escape the brackets. So when the server(Thin in my case) tries to render things through the awkward directories it's not escaping the brackets. Hopefully there's a way to escape the directory names, so I'm going to look there first.

Larz Conwell

Oh oops I didn't notice you already included the OS's and the Ruby/Rails versions

Shawn Falkner-Horine

That being said, the OS handles other characters the same way in directory names, characters which don't cause the same problem -- spaces and open parentheses "(" for instance, the former is already in the test cases above and the latter I just tested. (No problem repro with either.)

Larz Conwell

Ah okay I was just testing () haha parentheses do work, so that's kind of weird. I'm still looking around to see where it's being loaded at

Larz Conwell

I can't seem to find the cause. ):

Maybe @josevalim can help you resolve this problem or someone else from Rails core.

Jeremy Walker
iHiD commented

I've had a quick look into this.

Have you tried running rails s with bundler? (bundle exec rails s) That fails for me altogether if there is a [ in the path.
I then tried echo $PATH, which gives very different results depending on whether there is a [ or not.

This leads me to think that it's an OS issue or maybe an RVM issue.

Larz Conwell

Oh I should note! I ran a simple Rack app config.ru and it worked fine inside a directory with brackets.

Andrew White
Owner

This maybe an issue with static file serving in development. Does a dynamic page work okay?

I'm away from my computer at the moment - I'll investigate it later.

Larz Conwell

Same error about missing templates, when trying to render an instance var from the controller and simply displaying it in view.

Template is missing

Missing template post/index, application/index with {:locale=>[:en], :formats=>[:html], :handlers=>[:erb, :builder, :coffee]}. Searched in: * "/home/larz/Desktop/test [3]/hey/app/views"
Larz Conwell

So when you generate a scaffold or more specifically when generating a model, migrating the database won't work.

~/Desktop/test [3]/hey$ bundle exec rake db:migrate
~/Desktop/test [3]/hey$

So I moved the directory to my desktop migrated the database moved it back into the test [3] directory. After I start the server back up I get the same error as above about missing templates.

Andrew White
Owner

So it turns out there's a whole bunch of places where Dir.glob or Dir[] is used without the path being properly escaped for glob characters which is what's causing your problems. The thing is it's not just Rails itself, some of it's dependencies have similar problems so this isn''t going to be fixed quickly. My recommendation for the moment is to refrain from using * ? { } [ ] in any application paths. They should be fine in view paths and public paths as those should be escaped properly.

Larz Conwell

:+1: Thanks for the explanation.

@DreadPirateShawn Since this issue is quite large and would take some time to fix, you could use this shell script I made to rename all your files. https://gist.github.com/2689980
Though you might have to run it a couple times, to rename all the children folders as well.

Andrew White
Owner

We're thinking of addressing this by adding a boot-time check for the application path containing * ? { } [ ] that exits with a warning message. There's no way to reliably test that dependencies aren't subject to this issue so it's probably best if we don't support it.

@josevalim @jeremy @tenderlove are you happy with this solution?

Aaron Patterson
Owner

Exiting with a warning message does not sound good. I'm happy emitting a warning message and continuing, but we should actually be fixing our broken code (the dir glob usage) rather than enforcing particular directory names.

Andrew White
Owner

@tenderlove the only problem is it's everywhere - RubyGems, Thor, Bundler just before I can even start to test Rails. We can fix our code, we can issue PRs for each of our dependencies (e.g. erikhuda/thor#231) but we can't fix every gem that may be used in a Rails application so there's always a risk something may break.

If we emit a warning and continue then there needs to be some way that message can get switched off otherwise it just gets annoying. In that case I'd rather we just emit a warning if doing rails new inside an affected path.

Andrew White
Owner

Just to complicate matters Dir[] doesn't work properly on JRuby: jruby/jruby#172

Larz Conwell

I think issuing a warning when doing rails new would be a good solution. Not too intrusive but still explanatory enough so they realize they'll have issues.

Larz Conwell

But what if they decide to drop in an app in a directory with the glob characters? Should we also issue a warning when starting up the server?

Andrew White
Owner

Should we also issue a warning when starting up the server?

I'm :thumbsdown: on warnings that have no way of being turned off - either by fixing the problem or changing a config. By having a warning that shows every time we're basically telling the developer to rename the path to one without glob characters - you might as well just terminate on detecting an affected path, the effect is the same in the long run.

Aaron Patterson
Owner

@tenderlove the only problem is it's everywhere - RubyGems, Thor, Bundler just before I can even start to test Rails. We can fix our code, we can issue PRs for each of our dependencies (e.g. erikhuda/thor#231) but we can't fix every gem that may be used in a Rails application so there's always a risk something may break.

Sure. But using dir globs in this way is a bug, and all libraries have bugs. That doesn't mean we shouldn't depend on those libraries. We can fix our bugs, but we're not required to do the legwork on libraries we don't control. IOW, it's not the rails-core team's responsibility to ensure that all of the rails dependencies are bug free.

I'm fine with not emitting a warning either. But exiting the process just because a user has some arbitrary character in their path is completely wrong.

Piotr Sarnacki
Collaborator
drogus commented

@tenderlove if we know that it will blow up anyway, why is this wrong? I would rather like to get an error when trying to boot an app with nice explanation of the problem rather than some random failures that may or may not make sense.

Aaron Patterson
Owner
Piotr Sarnacki
Collaborator
drogus commented

@tenderlove ah, I thought that it was also because it fails in rails. If that's going to be fixed in Rails itself I agree that we should not raise.

Andrew White
Owner

@tenderlove @drogus have you seen @drbrain's response to rubygems/rubygems#331 ?

If waiting for Ruby to add an glob escaping method is their final response and given the jruby/jruby#172 issue I'm not sure what is the best way of fixing this anymore. Escape the glob characters and log a warning on JRuby until that's fixed?

Richard Schneeman
Collaborator

Looks like @drbrain nixed the fix in rubygems, I agree that getting this fixed across the board across all offending projects is a bit ambitious at best. While not common, this issue has appeared again in #6868. So the question remains, should we allow our supporting libraries to fall flat on their faces and just fix this in Rails, or issue a warning or error preemptively?

Eric Hodel

I can't find a feature request for adding a glob-escape method on http://bugs.ruby-lang.org, which is the best way to introduce a fix for this problem. "Fixing" this by patching hundreds of ruby libraries is a very poor way to go about this.

Perhaps someone interested in fixing this problem will open such a feature request.

(That was a hint)

Steve Klabnik steveklabnik closed this
Steve Klabnik
Collaborator

So.

I think that we're at a stalemate here. Ultimately, the fix in Ruby fixes it for everyone, and so I've requested this. Until a time as such as we're on that Ruby, it can't be fixed for sure everywhere, and rather than play bug whack-a-mole, I'm just going to give this a close as 'not actually our bug.'

If someone can come up with a solution that satisfies everyone in this discussion, we can implement that, but I can't see a path forward here.

Konstantin Haase
rkh commented

Dir#glob_escape could be implemented in pure Ruby, in ActivesSupport for instance. Or am I missing something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.