Use sys.executable for the fuzzywuzzy auto-install fallback

[ethando1984]

Problem

The fuzzywuzzy ImportError fallback in xsstrike.py shells out to a hardcoded pip3:

ret_code = os.system('pip3 install fuzzywuzzy')

pip3 resolves to whatever pip happens to be first on PATH, which is not necessarily the interpreter running XSStrike. That produces two failure modes:

1. Inside a virtualenv — pip3 may resolve outside the venv, so the package installs into a different environment. XSStrike then prints "fuzzywuzzy has been installed, restart XSStrike", but the next run fails the import again, in a loop.

2. On externally-managed installs (Homebrew, Debian/Ubuntu per PEP 668) — the install aborts outright:

   error: externally-managed-environment
   × This environment is externally managed
   

   The user sees a pip error with no obvious connection to XSStrike. This is likely related to the recurring "I installed the dependencies but it still says fuzzywuzzy isn't installed" reports, and is why the bug report template has to ask whether pip3 was used.

Fix

ret_code = subprocess.call([sys.executable, '-m', 'pip', 'install', 'fuzzywuzzy'])

sys.executable -m pip always targets the interpreter actually running the script, which is the standard recommendation for programmatic pip invocation.

Passing an argument list via subprocess.call instead of a shell string also avoids word-splitting — this matters because sys.executable contains spaces on macOS framework builds:

/opt/homebrew/Cellar/python@3.14/.../Python.app/Contents/MacOS/Python

import os is dropped since it existed only for the os.system call and os is unused elsewhere in the file. sys is imported at module level further down, but that is below this try block, so the local import inside the handler is still needed.

Testing

Exercised the fallback path rather than only reading it — created a venv with tld and requests but deliberately without fuzzywuzzy, then ran XSStrike under it:

• the auto-install fired and installed fuzzywuzzy into that venv
• global site-packages were left untouched
• XSStrike started normally afterward

Before the change, the same scenario on Homebrew Python failed with externally-managed-environment.

No behavior change when fuzzywuzzy is already present. Return-code handling is unchanged (subprocess.call returns the exit status, same as the existing ret_code != 0 check expects).

🤖 Generated with Claude Code