Fix a couple of tests when no “python” in path

[musicinmybrain]

These CLI tests assume a “python” executable is available outside of a virtualenv, which is not necessarily true (e.g. Fedora has only “python3” if the python-unversioned-command package is not installed). Use the value of sys.executable in the script configs for these tests instead.

I found this while working on Hatch 1.18.0 for Fedora because the new test test_interrupt_signal_not_inherited failed; I hadn’t noticed that it already affected test_scripts_no_environment because our builds are offline and test_scripts_no_environment has @pytest.mark.requires_internet.

[musicinmybrain]

On MacOS: /bin/sh: /Users/runner/Library/Application: No such file or directory

This is because sys.executable is something like /Users/runner/Library/Application Support/hatch/env/virtual/hatch/h61Cbry8/hatch-test.py3.14/bin/python3, the construction of the test config doesn’t do shell quoting, and there is whitespace in the path.

I suppose one option would be to assume that just having the correct executable name from sys.executable suffices, and that the executable name itself doesn’t have whitespace. These aren’t necessarily bulletproof assumptions, but they are probably good enough for testing, and still an improvement over a hard-coded python.

Another option would be to map sys.executable through shlex.quote, but this is only guaranteed to work properly for POSIXy shells.

[musicinmybrain]

I suppose one option would be to assume that just having the correct executable name from sys.executable suffices, and that the executable name itself doesn’t have whitespace. These aren’t necessarily bulletproof assumptions, but they are probably good enough for testing, and still an improvement over a hard-coded python.

I implemented this for now. Let’s see how it goes.