python
gh-75729: Fix os.spawn tests not handling spaces on Windows
As originally reported in #75729 and confirmed to still be reproducible on the latest Python 3.12, the various os.spawn* tests are broken on Windows if the current working directory contains any spaces in its path (e.g. due to spaces in the username), as on Windows the arguments are simply concatenated and not quoted. This PR fixes the immediate issue with the tests by quoting the arguments in question on Windows.
- Issue: gh-75729
Should this have a NEWS entry? I see some PRs that only change the tests have them, but many (perhaps most?) I spot-checked don't.
I think a NEWS entry is helpful here because this could affect redistributors or users who are trying to run the tests locally.
Thanks, I added one, but it seems there's something funny going on with GitHub, as when I pushed it failed multiple times with a strange error, even after I reset and re-committed:
remote: fatal error in commit_refs
To github.com:CAM-Gerlach/cpython.git
! [remote rejected] fix-spawn-tests-space-in-path -> fix-spawn-tests-space-in-path (failure)
error: failed to push some refs to 'github.com:CAM-Gerlach/cpython.git'
I then force pushed and my fork updated, but nothing happened here for several minutes. Finally I rebased and force-pushed again, and it appears to have updated here, but the GHA webhooks still aren't firing yet.
Good question, and at least as far as the scope of this PR, the os.spawn* tests are the only ones affected in the os module (there are a couple unrelated tests affected in other modules, which I will be opening separate issues/PRs for), when tested with both the interpreter path, the working dir path and the temp dir path all containing spaces (given they are all under a user directory containing such).
However, the os.exec* functions on Windows do have the same issue as the os.spawn* functions, a fact I will note on the corresponding issue—but their tests don't, because as far as I could find, there apparently are no tests of os.exec* where this issue would be triggered, since the only tests are for empty, invalid, etc. arguments that return with an exception before the bad behavior would be triggered at the OS level. I'm guessing this is because if os.exec* actually executed successfully, this would naturally break the tests, since the testing process would get replaced with whatever is launched.
It should be as far as I'm aware, yeah—there are some other issues that need another round of discussion, but we can at least fix the tests for now.
Thanks @CAM-Gerlach for the PR, and @hugovk for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11. 🐍🍒⛏🤖
