Hi Sean,

Thank you for asking! I guess the bug still exists. But you can close this bug if there are not many people complaining about this issue.

I don't have the GBK Chinese Windows at hand, so I cannot test all the 3 example cases.

I've just tested my example 3 (`cd` a Chinese directory) in a Shell mode buffer on an English (latin) Windows system with GNU Emacs 29.4. Emacs passed whitespaces (0x0A) to the Windows command line, instead of UTF-8 encoded string. Emacs detected that the process encoding system is latin, it cannot convert the UTF-8 encoded Chinese characters to the latin encoding, then it passes whitespaces as placeholders to the shell process. This behaviour is different from what I saw 15 years ago.

However, I don't think this is the right logic to handle the encoding conversion problem. The correct logic should be: try to get the OS encoding system, if it succeeds, try to encode the string using that encoding system and pass the encoded string to the subprocess, if failed, report error. However, the current behaviour is to use whitespaces as placeholders.

Best Regards,

Rui (Ryan) Duan