Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

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

Closed
DreadPirateShawn opened this Issue · 33 comments

10 participants

@DreadPirateShawn

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).

@DreadPirateShawn

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

@larzconwell

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

@DreadPirateShawn

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.

@larzconwell

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.

@DreadPirateShawn

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).

@larzconwell

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.

@larzconwell

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

@DreadPirateShawn

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.)

@larzconwell

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

@larzconwell

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

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

@iHiD

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.

@larzconwell

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

@pixeltrix
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.

@pixeltrix pixeltrix was assigned
@larzconwell

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"
@larzconwell

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.

@pixeltrix
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.

@larzconwell

:+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.

@pixeltrix
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?

@tenderlove
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.

@pixeltrix
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.

@pixeltrix
Owner

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

@larzconwell

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.

@larzconwell

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?

@pixeltrix
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.

@tenderlove
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.

@drogus
Collaborator

@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.

@tenderlove
Owner
@drogus
Collaborator

@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.

@pixeltrix
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?

@schneems
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?

@drbrain

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)

@steveklabnik
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.

@rkh

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.