<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Aug 2024 at 19:34, Naoto Sato <<a href="mailto:naoto.sato@oracle.com">naoto.sato@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br></blockquote><div><br></div><div>Hello Nato. Nice to meet you.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As I commented in the bug report, I closed the issue as "not an issue", <br>
as LC_* environment values on Windows has never been supported (or even <br>
considered) as a means to set locale/encoding as the way POSIX does. It <br>
would create some inconsistent state between Windows' locale settings <br>
which may cause some unexpected behavior in applications.<br></blockquote><div><br></div><div>We are talking not about the whole Windows but only about the MSYS2/MINGW console that has its own support of UTF-8 that is enabled by default. We also are talking about a console encoding exclusively and not about any other locale parameter. The 
MSYS2/MINGW console is widely used by many developers on Windows because of the Git popularity and the Git for Windows project that comes with the MINGW64 variant of MSYS2, including its UNIX-like console with UTF-8 enabled by default. Many software engineers use that console not just for running Git commands but also for doing many other things, including running Java console applications. There are some developers who use the MSYS2 project directly and also may run Java applications inside the MSYS2 console.</div><div><br></div><div>The 
LC_* environment variables are defined by MSYS2 only and not by Windows. The same is also true about  the
OSTYPE and MSYSTEM 
environment variables. The only problem using 
OSTYPE or MSYSTEM to identify MSYS2 in Java could be if cmd.exe is started from the MSYS2 console. In this case that cmd.exe process will inherit all environment variables, including the above that were set by MSYS2 previously. But practically I don't see any reason for anybody to run cmd.exe from MSYS2 console.</div><div><br></div><div>Ok but there is another way to identify that your process is running under MSYS2 by another, probably a more reliable way. You can find your parent process and check what DLLs it has loaded. If it has msys-2.0.dll loaded then your process is running under MSYS2 and not under cmd.exe even if that cmd.exe was started from MSYS2. Please take a look at the attached PoC code made by ChatGPT.</div><div><br></div><div>Example of how this PoC works after it was built by Visual Studio 2022 MSVC:</div><div><br></div><div>$ ./stam01.exe<br>Parent Process ID: 1460<br>Parent Process Name: bash.exe<br>Parent Process Full Path: C:\Program Files\Git\usr\bin\bash.exe<br>Loaded DLLs in Parent Process (ID: 1460):<br>        C:\Program Files\Git\usr\bin\bash.exe<br>        C:\Windows\SYSTEM32\ntdll.dll<br>        C:\Windows\System32\KERNEL32.DLL<br>        C:\Windows\System32\KERNELBASE.dll<br>        C:\Windows\System32\USER32.dll<br>        C:\Windows\System32\win32u.dll<br>        C:\Program Files\Git\usr\bin\msys-2.0.dll<br>        C:\Windows\System32\GDI32.dll<br>        C:\Windows\System32\gdi32full.dll<br>        C:\Windows\System32\msvcp_win.dll<br>        C:\Windows\System32\ucrtbase.dll<br>        C:\Windows\System32\advapi32.dll<br>        C:\Windows\System32\msvcrt.dll<br>        C:\Windows\System32\sechost.dll<br>        C:\Windows\System32\RPCRT4.dll<br>        C:\Windows\System32\bcrypt.dll<br>        C:\Windows\SYSTEM32\CRYPTBASE.DLL<br>        C:\Windows\System32\bcryptPrimitives.dll<br>        C:\Windows\System32\IMM32.DLL<br>Parent process has msys-2.0.dll loaded. Running under MSYS2.</div><div><br></div><div>D:\develop\cpp-tryouts\x64\Debug>stam01.exe<br>Parent Process ID: 13016<br>Parent Process Name: cmd.exe<br>Parent Process Full Path: C:\Windows\System32\cmd.exe<br>Loaded DLLs in Parent Process (ID: 13016):<br>        C:\Windows\System32\cmd.exe<br>        C:\Windows\SYSTEM32\ntdll.dll<br>        C:\Windows\System32\KERNEL32.DLL<br>        C:\Windows\System32\KERNELBASE.dll<br>        C:\Windows\System32\msvcrt.dll<br>        C:\Windows\System32\combase.dll<br>        C:\Windows\System32\ucrtbase.dll<br>        C:\Windows\System32\RPCRT4.dll<br>        C:\Windows\SYSTEM32\winbrand.dll<br>        C:\Windows\System32\bcrypt.dll<br>        C:\Windows\System32\sechost.dll<br>Parent process does not have msys-2.0.dll loaded. Likely running under native Windows.</div><div> </div><div>Once you have found that your parent process has msys-2.0.dll loaded, you can safely check the LC_* environment variables.</div><div>If the parent process doesn't have 
msys-2.0.dll loaded, continue to identify the console encoding as you do it now.</div><br></div><br></div>