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

Environment building fails on Windows under non-ASCII username #81

Closed
vassilevsky opened this issue Jul 8, 2014 · 3 comments
Closed
Labels

Comments

@vassilevsky
Copy link

The reason I opened #80 is that ChildProcess crashes when I run it. (And not some "clever" marketing BS that issue totally sounded like.)

I am Russian. When we Russians install Windows, it suggests that we use a Russian username. It even gives us an example: Андрей. Naturally, we all enter our names into the field and proceed, satisfied. (I actually entered Андрей once, when installing Windows 7 for my wife. She didn't get the joke.)

Thus, we end up having all our files in C:\Users\Андрей and a lot of environment variables having Андрей in their values because of that.

That's when things start to get weird.

Apparently, there's a bug in MRI. Not sure if it's Windows only. All values in ENV are in UTF-8 (which is awesome). But at the same time, their encoding is set to IBM866. And they're frozen.

Long story short, this line crashes with the IncompatibleEncodings exception:

https://github.com/jarib/childprocess/blob/master/lib/childprocess/windows/process_builder.rb#L63

I'll try to fix this situation and attach dem commits when I have some time & sleep.

P. S. I discovered this by attempting to run Vagrant.

@vassilevsky
Copy link
Author

MRI is fine. It gives you all ENV values encoded in the "external" encoding (IBM866 for me). No problem there.
The problem is only in ENV['GEM_HOME'] value. It has ASCII-8BIT encoding attached to it, but it's actually in UTF-8 or something like that. It seems that it comes from Vagrant this way.

@jarib jarib added the windows label Jun 9, 2016
@DavidS
Copy link
Contributor

DavidS commented Oct 2, 2017

@sds
Copy link
Collaborator

sds commented Jan 12, 2019

This is an old issue, but it seems like this would have likely been fixed by #134. Thanks for reporting!

@sds sds closed this as completed Jan 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants