Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the default windows install location is a unix location #135

Closed
Pomax opened this issue Sep 28, 2012 · 7 comments
Closed

the default windows install location is a unix location #135

Pomax opened this issue Sep 28, 2012 · 7 comments

Comments

@Pomax
Copy link

Pomax commented Sep 28, 2012

The default install location is c:\ruby193 (version number dependent on version, of course), but this is a protected location in modern Windows (vista/7, probably 8 too but I've not checked). Programs go into Program Files, so changing this location to "Program Files\Ruby\1.9.1" or, on 64 bit systems, "Program Files (x86)\Ruby\1.9.3" would be more in line with how windows programs are supposed to install themselves (program files -> company name, if relevant, usually isn't -> product name -> version, if installing a program that allows concurrent version installations)

@Azolo
Copy link
Member

Azolo commented Sep 28, 2012

Well there are a couple problems with that.

The main one being the problem pointed out in this troubleshooting section.

Secondly, the Program Files directories on Windows 7 are protected from all changes. Meaning that we would have to patch the installation and home gem directories, or get UAC permission every time someone wants to install a gem.

But the idea of programs not installing into Program Files isn't unprecedented. Google Chrome stopped using the Program Files directory quite long ago, and now installs into the User's Profile (specifically the local App Data).

But the main reason is still that we need, as you call it, a "unix location" to use some of the compilation tools. The restrictions put on Program Files and the desire for an easier development environment (No UAC trouble) would be my second argument.

I don't know if Luis would consider moving the default installation directory to another location that isn't the C:\ root, but Program Files isn't an option without breaking the conventional Ruby environment.

@Azolo Azolo closed this as completed Sep 28, 2012
@Pomax
Copy link
Author

Pomax commented Sep 28, 2012

admin permissions to install gems is pretty much essential. If it needs sudo in _n_x, it needs UAC on windows ;)

I wasn't aware of breaking the ruby env, things seem to work pretty well with it installed in Program Files for me, including installing gems using a UAC elevated command prompt (that might be because I haven't done anything that runs into a problem yet, but C:\ is just as protected as Program Files in windows 7. Or at least, should be, unless someone turned their UAC off)

@luislavena
Copy link
Member

but C:\ is just as protected as Program Files in windows 7. Or at least, should be, unless someone turned their UAC off)

That is incorrect. Only Program Files, Windows and Program Files (x86) are protected by UAC. I've even enabled higher UAC so I'm continuously annoyed by it to remember where is safe to store stuff.

You can install anything without elevation outside these folders.

Ruby, at this time, is not prepared to be installed inside Program Files due several reasons:

  • Path with spaces, as clearly warned by the installers and all the documentation, even the Ruby source
  • RubyGems default installation of gems relative to Ruby installation directory, which annoyingly requires elevation all the time.
  • Lot of gems that need to look out for files relative to it are not working properly with path that contain spaces

This situation is similar to Python, and is something the community has already assumed.

There are efforts to make Ruby a better citizen on Windows. Ruby 2.0 will be able to be installed in a path with spaces:

http://bugs.ruby-lang.org/issues/7036

Next is allow Windows determine the needed permissions to consider the installation directory valid to be written, which is something still need to be worked on.

I've covered some of the points in your other Issue (#134)

As you can see, there is lot to be done to make Ruby play better with Windows and fit under your expectations (and many others like sysadmins)

But this is a big task and we can't do it alone. Is not only RubyInstaller's contributors that need to work this out, is the entire community.

@Pomax
Copy link
Author

Pomax commented Sep 28, 2012

I see. That is unfortunate, and I hope it won't be too long before everyone agrees on how to support Windows. Thank you for the installer though, it's definitely easier than compiling from source.

@luislavena
Copy link
Member

I see. That is unfortunate, and I hope it won't be too long before...

And why wait until others deliver what you can help build?!?

Change starts by you.

As you can see from my statements, I'm not saying that you're wrong, on the contrary, I'm stating the current status and that we want (actually, need) help.

Why don't you help out? At the end of the day, it will also scratch your own itch and everybody will benefit. 😄

@Pomax
Copy link
Author

Pomax commented Sep 28, 2012

because those others actually have the skills required to pull it off, and I don't. Which is why I'm changing the world by working on other open source projects, some of which require me to have ruby installed =)

@luislavena
Copy link
Member

I'm changing the world by working on other open source projects

Well, was worth the attempt 😉

larskanis added a commit to oneclick/rubyinstaller2 that referenced this issue Nov 26, 2022
For several reasons we use C:/RubyXXX direcory by default but not C:/Program Files.
See: oneclick/rubyinstaller#135

Using an install path under C:/ inherits write permissions for everyone, which is compromizes security in a multi user environment.
As a countermeasure this commit restricts write permissions to the installing user.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@luislavena @Azolo @Pomax and others