Closed eine closed 1 month ago
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.
@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, I did not check whether this is a problem with
pytest
only, or with any Python script which usescheck_call
or other resources fromsubprocess
.
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.
@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 https://github.com/msys2/setup-msys2/commit/c167722af9b757063fd9c0e21f6aeb689e9d076a. So, it is not a native Windows app, but a multiplatform testsuite composed mainly of a pytest script and shell/bash scripts.
This is the result if bash
is not called:
Ref msys2/msys2-autobuild#1
I guess the only thing we can do here is add a section about bash.exe and tar.exe in the README.
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
I've created https://github.com/msys2/msys2.github.io/issues/334 so we document this at some point.
Nothing that needs fixing in setup-msys2, so closing this.
Recently, GitHub added WSL to the virtual environment used in GitHub Actions (actions/virtual-environments#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 withstrict
. However, it might be conflictive for users of modeinherit
.Moreover, in Python, when
pytest
is used along withcheck_call(['bash',...])
, it is resolved toC:\Windows\System32\bash.exe
and it fails if the user has not explicitly configured WSL before. A workaround is to usewhich
fromshutil
. See https://github.com/actions/virtual-environments/pull/1081#issuecomment-661524144.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
vswin32
)./cc @The-Compiler