locale not passed WSL's git; leads to unpredictable errors when Win apps need specific Git locale

[diablodale]

When a process in Windows runs WSLgit and passes a locale variable (e.g. LC_ALL, LANG, etc.) on that spawn, that variable is not passed to WSL. Therefore, the specific locale requested for Git is ignored and can lead to errors as in in gitkraken/vscode-gitlens#276

This is due to environment variables set in Win32 not being seen in WSL. Good news. This does become possible in Windows 10 build 17063 by configuring the WSLENV variable as in https://blogs.msdn.microsoft.com/commandline/2017/12/22/share-environment-vars-between-wsl-and-windows/

Here are two ideas to resolve this. Any others?

1. Close this issue as won't fix and keep it for people to find/learn from later. Unfortunately, isolating the cause of the errors will be difficult because the error is from some Windows process yet caused by an interaction between WSLgit and WSL. I only am aware of it because I was the OP on that GitLens issue above.
2. Update the WSLgit code to configure the WSLENV variable for any found LANG or LC_xxx environment variables. While this will resolve locale, it feels somewhat "chasing a neverending problem" because there are more environment variables on which Git responds. For example, GitLens sets three here gitkraken/vscode-gitlens@6889e2a and all are being dropped by WSLgit

[andy-5]

That's an interesting problem.

I agree with you on both 1. and 2. An alternative might be to require users to setup WSLENV accordingly once (globally). I assume it is not a problem if WSLENV contains variables that are not set on Windows, so nothing changes when the variables are not set by any tool. Once vscode-gitlens or any other tool sets the variables, they are automatically forwarded by WSL.

We could add some documentation stating that passing environment variables requires them to be setup in WSLENV also.

[diablodale]

You wrote "I assume it is not a problem if WSLENV contains variables that are not set on Windows..."

Unfortunately, sometimes it is a problem. While spanning across WSLgit and GitLens, I found a bug in WSL microsoft/WSL#3018. Somewhere in the WSL codebase, they get the lang-locale from Win32 and set it in Ubuntu. However, Microsoft didn't consider the interaction of that with the WSLENV functionality.

I might have a clearer suggestion of our three ideas...but I don't have a feeling for which one helps the users of WSLgit more and/or doesn't cause more problems. For example, with your idea - to doc the need for WSLENV and other vars...

1. Which vars do we ask people to put in WSLENV? If there is a definitive list, WSLgit could do it in code.
2. Does a user have to divine the list of vars? How would anyone know WSLENV=LANG was needed to solve the problem with GitLens + WSLgit? That's a tough issue to isolate.
3. All of the vars which are programmatically set on the process will be difficult. It is not the norm for an app/tool to document env vars it sets on child processes.
4. Because of the bug I found in WSL, a user has to always set their LANG if it is listed within WSLENV. And that value has to be exactly correct, e.g. "en_US.UTF-8" with all its underscores, periods, and dashes. Getting that string exactly correct was trial/error for me.

Number 3 above I think is the hardest for a user. These are vars which are never seen in the Windows control panel or any command prompt. They come and go in a millisecond - yet can significantly change behavior. And are not documented by the app/tool. I looked in the Win32 APIs and I didn't see an easy way, given a env variable, from where did it come (process, user, or system). It is possible to manually query the registry for the user and system env variables - and from that resolve the var's source. I think the code can be written, but suspect it will be buggy as we work through the various edge cases.

As reference, a list of vars Git uses https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables. It doesn't list LANG, LC_xxx, or GCM_xxx so there are likely others not on this page.

[carlolars]

Are there actually that many enviornment variables that are relevant?

• LANG, LC_* - If any exists they should be passed to WSL.
• GIT_* - If any exists then pass to WSL.

The GCM_* variables are for Git Credential Manager which is a windows application, and a variable that is set on the Win-side is still available for Win-applications even if they are called from WSL and the variable never was shared to WSL. So there is no need to share those variables.