[go: nahoru, domu]

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

bug: pyenv changes code page (on a German Windows10) to code page 1250 #344

Open
pauschar opened this issue Jan 3, 2022 · 5 comments
Open
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@pauschar
Copy link
pauschar commented Jan 3, 2022

Describe the bug
A standard German keyboard comes with so-called 'Umlauten' (ä,ü.ö). sitting next to 'p' and 'l'.
Invoking `pyenv' seems to replace these keys with something different - see screenshot.

To Reproduce
Steps to reproduce the behavior:

  1. on a (windows) machine fire up a shell, powershell or alike
  2. type sth using the Umlaute keys: ääääüüüüüööö
  3. invoke pyenv
  4. repeat step 2: Now, the Umöaute keys have been redefined.

Expected behavior
Umlaute keys should not be redefined.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: Win10
  • Tools used: command prompt, e.g. Powershell
  • Version: 2.64.11

Additional context
Add any other context about the problem here.
Annotation 2022-01-03 122342

@pauschar
Copy link
Author
pauschar commented Jan 3, 2022

a closer look into the Windows Terminal Properties seems to indicate that pyenv changes the code page:
The default code page on my system is 437 (OEM - United States) _prior_ to invoking pyenvand1250 (ANSI - Central Europe` afterwards.
Annotation 2022-01-03 125010

@pauschar pauschar changed the title bug: 'Umlaut' keys on German keyboard are changed after pyenv is invoked for the 1st time bug: pyenv changes code page (on a German Windows10) to code page 1250 Jan 3, 2022
@kirankotari kirankotari added bug Something isn't working help wanted Extra attention is needed labels May 24, 2022
@kirankotari
Copy link
Member
kirankotari commented May 24, 2022

Yes, we are changing code pages in the following lines

@sunavlis
Copy link
sunavlis commented Jan 5, 2023

Yes, we are changing code pages in the following lines [..]

Why does pyenv change the code pages?

I see some issues with it in one of my docker images...

@azscrs
Copy link
azscrs commented Jan 17, 2023

Hej @sunavlis

I think I am facing the same issue on a win-servercore image, any updates on this?

I see there are suggestions in place here in #270

@yutotakano
Copy link
yutotakano commented Jul 16, 2023

I got bit by this problem too, where a file-read from a different program would work before Python is called, but would fail afterwards due to a change in codepages. My workaround right now is to add a chcp 65001 to reset it to what it was before the python call, but it's very annoying.

As far as I'm seeing from #88, chcp 65001 works fine for Python3 doesn't it? It's the default codepage for Windows if you enable UTF-8 support too, and it's the natural best codepage.

One idea is to make it conditional so that:

  • if running any version of Python3, use chcp 65001
  • if running any Python2, use chcp 1250
  • and the codepage gets reset to whatever it was after execution to prevent lingering effects as it does now

However, this'll still suffer from problems if you do any subprocess calls from Python, since they'll see a different codepage to what you see.

Another thought entirely (and one I like much more) is that pyenv-win shouldn't try to manage codepages at all. The root cause of all of this is #51, which mostly would've been fixed had the user changed their codepage in advance. I feel like it's an expected problem they encountered, and one they would've encountered anyway with other programs too (probably even a regular Python2 install too). It's one pyenv-win isn't obliged to try to fix. People have different codepages. A tool shouldn't try to change essentially a terminal/system setting silently, causing inconveniences for the rest of us who are happy with their use of codepages.

So my suggestion is to remove that chcp command entirely from the batch scripts. Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

5 participants