This bug was discovered by@Borda in#1888. Because that PR's central focus is tooling to catch typos, I'm creating this issue so that this bug in the test suite is clear, and so it will not be forgotten regardless of how development proceeds there. This affects three test cases intest_index.py.

In#1777, I introducedtest_run_commit_hook. This is expected to fail in a couple of situations where it should nonetheless be feasible to run the test suite. One of these is when the tests are run on a (native) Windows system that has nobash that can be found in a path search, neither inSystem32 or otherwise and neither WSL-related or otherwise. The test included an xfail marking to cover that case:

In that PR I also added those xfail markings to other tests to which they applied, and I used copy and paste to reproduce the parts that should be exactly the same across them.

But that contains a typo, passing arasies argument when constructing the mark, rather than the correctraises argument. The wrong argument is apparently ignored, so the marking is unconstrained, and even if those tests fail with a different exception -- one that is not covered by other xfail markings, and that is not intended to be covered by the ones with the misspelling, includingAssertionError from anassert statement in the test -- the problem would not be caught.

This is distinct from the more common problem of misspelling a mark, which is also not an error, but whichpytest does have the ability to warn about.

Fortunately, the way those tests fail is as the xfail markings attempt to describe and will actually describe once fixed. I have retested the cases not covered on CI, and they work with the changes totest_index.py appearing ina20d5db (#1888). I only checked out the changes totest_index.py in testing this, not the other files. In a virtual machine running Windows Server 2022 (version 10.0.20348), I have just tested the cases where:

• bash.exe exists, is the WSL-related command inSystem32, but there is no WSL system installed.
• bash.exe exists, is not the WSL-related command inSystem32 but is instead Git Bash, and is working.
• bash.exe does not exist anywhere found in aPopen call, not even inSystem32.

The latter case I believe still occurs on some Windows systems that nothing unusual has been done to, but is rare because usually a WSL-relatedbash.exe appears inSystem32 even if WSL is not installed, and (non-shell) path search on Windows generally includesSystem32 automatically, and even places it beforePATH directories even if it appears late or not at all inPATH.

(I retested it the same way I had done originally: by saving a snapshot to restore, then usingNanaRun MinSudo to run a shell as the special TrustedInstaller user, which is permitted to delete even specially protected files inSystem32. I suggest against doing such a thing outside a virtual machine; I snapshotted the VM first and restored it after the test.)