Run under cmd with default codepage 65001

[We-unite]

I used w64devkit in cmd in win10 before, under the default codepage ANSI(chcp 936. It works well. Now I modified the default codepage of cmd to UTF-8 (chcp 65001) by modifying HKEY_CURRENT_USER\Console\%SystemRoot%_system32_cmd.exe\CodePage of the registry. Then I noticed that running the commands in w64devkit directly in cmd (ls, mv, bash, etc.) echos nothing and seems to be stuck; However, if I run the chcp commands (chcp 936, or even chcp 65001) after cmd starts, it is normal to use these commands again.

Issue #162 mentioned that the distributed busybox doesn't support Unicode, but I'm not sure if that relates to what I'm talking about.

So I would like to ask, why does the default setting 65001 causes error, but then chcp 65001 make everything normal?

[skeeto]

Thanks for taking the time to report this. So far I'm unable to reproduce the issue. I created that registry key on Windows 10, and a DWORD CodePage entry with 65001. When I run cmd.exe directly, chcp confirms the 65001 codepage by default, so the registry entry is working. So then I run a fresh cmd.exe, invoke ls.exe directly, and works fine. Same results if I add it to PATH with set first, then "ls".

mentioned that the distributed busybox doesn't support Unicode

Starting in w64dk 2.1.0, UTF-8 is enabled in busybox-w32 in x64 builds. The feature is incompatible with Windows XP (binary won't even start), so it's disabled in x86 builds. I assume you're using x64, but I tried the above with both x86 and x64 builds without seeing this issue.

[We-unite]

Thanks for taking the time to report this. So far I'm unable to reproduce
the issue. I created that registry key on Windows 10, and a DWORD CodePage
entry with 65001. When I run cmd.exe directly, chcp confirms the 65001
codepage by default, so the registry entry is working. So then I run a
fresh cmd.exe, invoke ls.exe directly, and works fine. Same results if I
add it to PATH with set first, then "ls".
mentioned that the distributed busybox doesn't support Unicode
Starting in w64dk 2.1.0, UTF-8 is enabled in busybox-w32 in x64 builds.
The feature is incompatible with Windows XP (binary won't even start), so
it's disabled in x86 builds. I assume you're using x64, but I tried the
above with both x86 and x64 builds without seeing this issue.

Thanks for answering. I've tried the same thing on virtual machine win10, and it can't be reprouced, too. But it does on my x64 win10. I'm still trying to find out the reason.