Conflicts with pytest and WSL

[eine]

Recently, GitHub added WSL to the virtual environment used in GitHub Actions (actions/runner-images#1081). As a result, C:\Windows\System32\bash.exe is created. This is NOT an issue for users of setup-msys2 with the default path-type or with strict. However, it might be conflictive for users of mode inherit.

Moreover, in Python, when pytest is used along with check_call(['bash',...]), it is resolved to C:\Windows\System32\bash.exe and it fails if the user has not explicitly configured WSL before. A workaround is to use which from shutil. See actions/runner-images#1081 (comment).

Curiously, the problem is found in MINGW terminals only, not in MSYS. See https://github.com/msys2/setup-msys2/runs/892341986. I think it is because https://github.com/msys2/setup-msys2/runs/892341986?check_suite_focus=true#step:6:7 and https://github.com/msys2/setup-msys2/runs/892341966?check_suite_focus=true#step:6:7 (platform msys vs win32).

/cc @The-Compiler

[lazka]

I'd guess cygwin (and thus the msys Python build) has it's own exe lookup and thus ignores the system directory. Since our bash is always first in our PATH, things shouldn't be a problem independent of pathtype.

Not sure if there is anything we can do here, except to suggest users to delete %SYSTEM32%\\bash.exe if it is a problem.

[eine]

@lazka, I did not check whether this is a problem with pytest only, or with any Python script which uses check_call or other resources from subprocess.

Not sure if there is anything we can do here, except to suggest users to delete %SYSTEM32%\bash.exe if it is a problem.

Using shutil.which('bash') instead of 'bash' solves the issue. If this is reproducible with any Python script that uses subprocess.* and 'bash', I believe we should add a comment in the README. If this is not specific to the virtual environment, but it can be reproduced on any host with MSYS2 and WSL, it might need to be documented somewhere else.

[lazka]

@lazka, I did not check whether this is a problem with pytest only, or with any Python script which uses check_call or other resources from subprocess.

I'd guess any API which calls CreateProcess() internally. But, the question is why would any native Windows app call "bash.exe"? I'd guess that this is a corner case and/or hack in most cases.

[eine]

@lazka, the use case is using pytest in MINGW32/MINGW64 to handle multiple test scripts. Some are makefiles, other are python scripts, other are shell scripts. See c167722. So, it is not a native Windows app, but a multiplatform testsuite composed mainly of a pytest script and shell/bash scripts.

[eine]

This is the result if bash is not called:

• f01e00c
• https://github.com/msys2/setup-msys2/runs/899776128?check_suite_focus=true

[eine]

Ref msys2/msys2-autobuild#1

[lazka]

I guess the only thing we can do here is add a section about bash.exe and tar.exe in the README.

[Biswa96]

The WSL's bash.exe is also get confused with a meson build. CI runs System32/bash.exe while calling find_program() with a shell script. Here is the project's meson.build file https://github.com/Genymobile/scrcpy/blob/master/server/meson.build