Rails route helpers inexplicably add "postinstall" to requests

Question

* Listening on tcp://0.0.0.0:3000 Started GET "postinstall/" for 127.0.0.1 at 2013-10-27 07:26:15 +0000 ActiveRecord::SchemaMigration Load (1.8ms) SELECT "schema_migrations".* FROM "schema_migrations" 

This is basically this, all of my buttons are related to helpers like:

 new_user_registration GET /users/sign_up(.:format) registrations#new edit_user_registration GET /users/edit(.:format) registrations#edit 

Only links are:

 http://localhost:3000/postinstall/users/sign_in 

I went through my journal, and at some point, the requests simply begin to be effectively poisoned by this postinstall business.

I went for "postinstall" because of course this word cannot come from nowhere. I decided to sleep on it because I thought it was a stupid mistake, but now I need help, and unlike 99.9% of my previous questions, it seems that no one answered.

A search for even the "postinstall" query on Google gives terrible results.

I THINK my problem is the path helper, everywhere "postinstall" gets an addition to the requests / urls: the path is called like this:

 <a href="/users/sign_in" class="btn btn-success">Test</a> <%= link_to "Sign In", new_user_session_path, :class => "btn btn-success" %> 

If the first link will work in OK mode, but then the buttons to send the login form try to install POST in / postinstall / users / sign _in, etc. The second button will be a link to / postinstall / users, etc.

I have no idea how it started, I was over git log and even returned 3 or 4 days (this problem started last night), the error still persists.

Whether this is apparently specific to my Mac too, deployed to a dev site (Ubuntu) without any problems. I restarted my Mac etc. Any help is much appreciated ...

Answer 1

I had the same problem.

I use puma as a web server, and puma uses an ENV called "SCRIPT_NAME" that was set to "postinstall" after I installed the software by doing puma "postinstall" on the url.

if you still have this problem, cancel SCRIPT_NAME var from ENV using the shell unset SCRIPT_NAME .

Answer 2

If you use TotalTerminal, the last update leaves the SCRIPT_NAME environment variable set after the update. Rebooting the computer solves the problem.

I started a new topic on the binary support site to try to install this: http://discuss.binaryage.com/t/totalterminal-update-overrides-script-name-breaks-webservers/897