fix(scriptutils): fix path resolution and wildcard extraction for absolute shebangs by mcexit · Pull Request #345 · python/pymanager

mcexit · 2026-05-22T09:02:01Z

Description

This PR resolves a critical issue where scripts utilizing absolute or explicit relative shebangs (such as those generated by modern virtual environment managers like uv) are incorrectly intercepted, truncated, or routed to the wrong interpreter.

🐛 The Bugs

The original logic in _find_shebang_command heavily relied on pathlib.PurePath.match(). Because match() performs a loose right-aligned suffix match, PurePath("C:/uv/python.exe").match("python.exe") evaluates to True. This caused a chain reaction of unintended behaviors:

The is_default Trap: Absolute paths like C:\...\python.exe incorrectly triggered the is_default check, discarding the user's isolated environment and defaulting to the system-wide global Python.
The Wildcard Slicing Bug: The fallback check for python*.exe would intercept executables like C:\...\python_uv_test.exe and blindly slice the name ([6:-4]), causing the system to search for a phantom runtime tag (e.g., [ERROR] No runtime installed that matches _uv_test) and crash.
Relative Execution Trap:sh_cmd.match(i["executable"]) could falsely intercept absolute shebangs if a registered runtime was using a relative executable name.

🛠️ The Fix

is_name_only Check: Introduced a check for path separators (/ or \) to properly distinguish between "bare names" (like py.exe or python3.14.exe) and explicit paths (C:\...\python.exe or ./python.exe).
NOTE: This is significantly safer than checking len(sh_cmd.parts) == 1, which breaks explicit normalized relative paths (like #!./python.exe) by stripping the ./ and incorrectly flagging them as bare names.
Gated Fallbacks: Virtual alias lookup, the is_default override, and the tag extraction wildcards are now safely gated behind is_name_only.
Absolute vs Relative Validation: Added a condition (not PurePath(i["executable"]).is_absolute()) to prevent absolute shebangs from falsely matching relative executable registries.

🧪 Impact

With these changes, absolute paths are safely bypassed in the virtual lookup traps, allowing them to cleanly fall through to the LookupError at the end of the block. This exception is caught gracefully by _parse_shebang, which delegates the absolute path to shutil.which() under _find_on_path().

This restores 100% interoperability with tools like uv and explicit local paths (./python.exe), without breaking any existing PEP 397/PEP 486 behaviors for standard bare names.

…bare name rules `PurePath.match()` performs right-aligned suffix matching, which caused absolute shebang paths (e.g., `C:\uv\python.exe`) to inadvertently evaluate true for bare names like `python.exe` or `python*.exe`. This resulted in two critical bugs: 1. Virtual environment paths were hijacked by the `is_default` trap, falling back to the global default Python runtime instead of the specified one. 2. Custom executables (like `python_uv_test.exe`) were intercepted by the fallback wildcard search, resulting in arbitrary slicing and lookup errors for phantom version tags (e.g., `_uv_test`). This commit introduces an `is_name_only` check (validating the absence of directory separators `/` and `\`) to safely distinguish bare commands from explicit paths. Gating the `is_default`, virtual alias, and wildcard extraction logic behind this check ensures explicit paths correctly fall through to `_find_on_path()`.

python-cla-bot · 2026-05-22T09:02:06Z

All commit authors signed the Contributor License Agreement.

zooba · 2026-05-22T10:06:06Z

Please file an issue first, and leave out the cheesy headings and just focus on the problem you're observing and the context it appears in.

zooba · 2026-05-22T10:07:04Z

Also, if an issue is "critical", please submit it as a security report using the Github Security Advisory feature. Otherwise, please refrain from assessing the severity of an issue - we can handle that, taking into account more than one single user.

mcexit · 2026-05-22T09:02:01Z

Description

This PR resolves a critical issue where scripts utilizing absolute or explicit relative shebangs (such as those generated by modern virtual environment managers like uv) are incorrectly intercepted, truncated, or routed to the wrong interpreter.

🐛 The Bugs

The original logic in _find_shebang_command heavily relied on pathlib.PurePath.match(). Because match() performs a loose right-aligned suffix match, PurePath("C:/uv/python.exe").match("python.exe") evaluates to True. This caused a chain reaction of unintended behaviors:

The is_default Trap: Absolute paths like C:\...\python.exe incorrectly triggered the is_default check, discarding the user's isolated environment and defaulting to the system-wide global Python.
The Wildcard Slicing Bug: The fallback check for python*.exe would intercept executables like C:\...\python_uv_test.exe and blindly slice the name ([6:-4]), causing the system to search for a phantom runtime tag (e.g., [ERROR] No runtime installed that matches _uv_test) and crash.
Relative Execution Trap:sh_cmd.match(i["executable"]) could falsely intercept absolute shebangs if a registered runtime was using a relative executable name.

🛠️ The Fix

is_name_only Check: Introduced a check for path separators (/ or \) to properly distinguish between "bare names" (like py.exe or python3.14.exe) and explicit paths (C:\...\python.exe or ./python.exe).
NOTE: This is significantly safer than checking len(sh_cmd.parts) == 1, which breaks explicit normalized relative paths (like #!./python.exe) by stripping the ./ and incorrectly flagging them as bare names.
Gated Fallbacks: Virtual alias lookup, the is_default override, and the tag extraction wildcards are now safely gated behind is_name_only.
Absolute vs Relative Validation: Added a condition (not PurePath(i["executable"]).is_absolute()) to prevent absolute shebangs from falsely matching relative executable registries.

🧪 Impact

With these changes, absolute paths are safely bypassed in the virtual lookup traps, allowing them to cleanly fall through to the LookupError at the end of the block. This exception is caught gracefully by _parse_shebang, which delegates the absolute path to shutil.which() under _find_on_path().

This restores 100% interoperability with tools like uv and explicit local paths (./python.exe), without breaking any existing PEP 397/PEP 486 behaviors for standard bare names.

…bare name rules `PurePath.match()` performs right-aligned suffix matching, which caused absolute shebang paths (e.g., `C:\uv\python.exe`) to inadvertently evaluate true for bare names like `python.exe` or `python*.exe`. This resulted in two critical bugs: 1. Virtual environment paths were hijacked by the `is_default` trap, falling back to the global default Python runtime instead of the specified one. 2. Custom executables (like `python_uv_test.exe`) were intercepted by the fallback wildcard search, resulting in arbitrary slicing and lookup errors for phantom version tags (e.g., `_uv_test`). This commit introduces an `is_name_only` check (validating the absence of directory separators `/` and `\`) to safely distinguish bare commands from explicit paths. Gating the `is_default`, virtual alias, and wildcard extraction logic behind this check ensures explicit paths correctly fall through to `_find_on_path()`.

python-cla-bot · 2026-05-22T09:02:06Z

All commit authors signed the Contributor License Agreement.

zooba · 2026-05-22T10:06:06Z

Please file an issue first, and leave out the cheesy headings and just focus on the problem you're observing and the context it appears in.

zooba · 2026-05-22T10:07:04Z

Also, if an issue is "critical", please submit it as a security report using the Github Security Advisory feature. Otherwise, please refrain from assessing the severity of an issue - we can handle that, taking into account more than one single user.

mcexit · 2026-05-22T09:02:01Z

Description

This PR resolves a critical issue where scripts utilizing absolute or explicit relative shebangs (such as those generated by modern virtual environment managers like uv) are incorrectly intercepted, truncated, or routed to the wrong interpreter.

🐛 The Bugs

The original logic in _find_shebang_command heavily relied on pathlib.PurePath.match(). Because match() performs a loose right-aligned suffix match, PurePath("C:/uv/python.exe").match("python.exe") evaluates to True. This caused a chain reaction of unintended behaviors:

The is_default Trap: Absolute paths like C:\...\python.exe incorrectly triggered the is_default check, discarding the user's isolated environment and defaulting to the system-wide global Python.
The Wildcard Slicing Bug: The fallback check for python*.exe would intercept executables like C:\...\python_uv_test.exe and blindly slice the name ([6:-4]), causing the system to search for a phantom runtime tag (e.g., [ERROR] No runtime installed that matches _uv_test) and crash.
Relative Execution Trap:sh_cmd.match(i["executable"]) could falsely intercept absolute shebangs if a registered runtime was using a relative executable name.

🛠️ The Fix

is_name_only Check: Introduced a check for path separators (/ or \) to properly distinguish between "bare names" (like py.exe or python3.14.exe) and explicit paths (C:\...\python.exe or ./python.exe).
NOTE: This is significantly safer than checking len(sh_cmd.parts) == 1, which breaks explicit normalized relative paths (like #!./python.exe) by stripping the ./ and incorrectly flagging them as bare names.
Gated Fallbacks: Virtual alias lookup, the is_default override, and the tag extraction wildcards are now safely gated behind is_name_only.
Absolute vs Relative Validation: Added a condition (not PurePath(i["executable"]).is_absolute()) to prevent absolute shebangs from falsely matching relative executable registries.

🧪 Impact

With these changes, absolute paths are safely bypassed in the virtual lookup traps, allowing them to cleanly fall through to the LookupError at the end of the block. This exception is caught gracefully by _parse_shebang, which delegates the absolute path to shutil.which() under _find_on_path().

This restores 100% interoperability with tools like uv and explicit local paths (./python.exe), without breaking any existing PEP 397/PEP 486 behaviors for standard bare names.

…bare name rules `PurePath.match()` performs right-aligned suffix matching, which caused absolute shebang paths (e.g., `C:\uv\python.exe`) to inadvertently evaluate true for bare names like `python.exe` or `python*.exe`. This resulted in two critical bugs: 1. Virtual environment paths were hijacked by the `is_default` trap, falling back to the global default Python runtime instead of the specified one. 2. Custom executables (like `python_uv_test.exe`) were intercepted by the fallback wildcard search, resulting in arbitrary slicing and lookup errors for phantom version tags (e.g., `_uv_test`). This commit introduces an `is_name_only` check (validating the absence of directory separators `/` and `\`) to safely distinguish bare commands from explicit paths. Gating the `is_default`, virtual alias, and wildcard extraction logic behind this check ensures explicit paths correctly fall through to `_find_on_path()`.

python-cla-bot · 2026-05-22T09:02:06Z

All commit authors signed the Contributor License Agreement.

zooba · 2026-05-22T10:06:06Z

Please file an issue first, and leave out the cheesy headings and just focus on the problem you're observing and the context it appears in.

zooba · 2026-05-22T10:07:04Z

Also, if an issue is "critical", please submit it as a security report using the Github Security Advisory feature. Otherwise, please refrain from assessing the severity of an issue - we can handle that, taking into account more than one single user.

mcexit · 2026-05-22T09:02:01Z

Description

This PR resolves a critical issue where scripts utilizing absolute or explicit relative shebangs (such as those generated by modern virtual environment managers like uv) are incorrectly intercepted, truncated, or routed to the wrong interpreter.

🐛 The Bugs

The original logic in _find_shebang_command heavily relied on pathlib.PurePath.match(). Because match() performs a loose right-aligned suffix match, PurePath("C:/uv/python.exe").match("python.exe") evaluates to True. This caused a chain reaction of unintended behaviors:

The is_default Trap: Absolute paths like C:\...\python.exe incorrectly triggered the is_default check, discarding the user's isolated environment and defaulting to the system-wide global Python.
The Wildcard Slicing Bug: The fallback check for python*.exe would intercept executables like C:\...\python_uv_test.exe and blindly slice the name ([6:-4]), causing the system to search for a phantom runtime tag (e.g., [ERROR] No runtime installed that matches _uv_test) and crash.
Relative Execution Trap:sh_cmd.match(i["executable"]) could falsely intercept absolute shebangs if a registered runtime was using a relative executable name.

🛠️ The Fix

is_name_only Check: Introduced a check for path separators (/ or \) to properly distinguish between "bare names" (like py.exe or python3.14.exe) and explicit paths (C:\...\python.exe or ./python.exe).
NOTE: This is significantly safer than checking len(sh_cmd.parts) == 1, which breaks explicit normalized relative paths (like #!./python.exe) by stripping the ./ and incorrectly flagging them as bare names.
Gated Fallbacks: Virtual alias lookup, the is_default override, and the tag extraction wildcards are now safely gated behind is_name_only.
Absolute vs Relative Validation: Added a condition (not PurePath(i["executable"]).is_absolute()) to prevent absolute shebangs from falsely matching relative executable registries.

🧪 Impact

With these changes, absolute paths are safely bypassed in the virtual lookup traps, allowing them to cleanly fall through to the LookupError at the end of the block. This exception is caught gracefully by _parse_shebang, which delegates the absolute path to shutil.which() under _find_on_path().

This restores 100% interoperability with tools like uv and explicit local paths (./python.exe), without breaking any existing PEP 397/PEP 486 behaviors for standard bare names.

…bare name rules `PurePath.match()` performs right-aligned suffix matching, which caused absolute shebang paths (e.g., `C:\uv\python.exe`) to inadvertently evaluate true for bare names like `python.exe` or `python*.exe`. This resulted in two critical bugs: 1. Virtual environment paths were hijacked by the `is_default` trap, falling back to the global default Python runtime instead of the specified one. 2. Custom executables (like `python_uv_test.exe`) were intercepted by the fallback wildcard search, resulting in arbitrary slicing and lookup errors for phantom version tags (e.g., `_uv_test`). This commit introduces an `is_name_only` check (validating the absence of directory separators `/` and `\`) to safely distinguish bare commands from explicit paths. Gating the `is_default`, virtual alias, and wildcard extraction logic behind this check ensures explicit paths correctly fall through to `_find_on_path()`.

python-cla-bot · 2026-05-22T09:02:06Z

All commit authors signed the Contributor License Agreement.

zooba · 2026-05-22T10:06:06Z

Please file an issue first, and leave out the cheesy headings and just focus on the problem you're observing and the context it appears in.

zooba · 2026-05-22T10:07:04Z

Also, if an issue is "critical", please submit it as a security report using the Github Security Advisory feature. Otherwise, please refrain from assessing the severity of an issue - we can handle that, taking into account more than one single user.

mcexit · 2026-05-22T09:02:01Z

Description

This PR resolves a critical issue where scripts utilizing absolute or explicit relative shebangs (such as those generated by modern virtual environment managers like uv) are incorrectly intercepted, truncated, or routed to the wrong interpreter.

🐛 The Bugs

The original logic in _find_shebang_command heavily relied on pathlib.PurePath.match(). Because match() performs a loose right-aligned suffix match, PurePath("C:/uv/python.exe").match("python.exe") evaluates to True. This caused a chain reaction of unintended behaviors:

The is_default Trap: Absolute paths like C:\...\python.exe incorrectly triggered the is_default check, discarding the user's isolated environment and defaulting to the system-wide global Python.
The Wildcard Slicing Bug: The fallback check for python*.exe would intercept executables like C:\...\python_uv_test.exe and blindly slice the name ([6:-4]), causing the system to search for a phantom runtime tag (e.g., [ERROR] No runtime installed that matches _uv_test) and crash.
Relative Execution Trap:sh_cmd.match(i["executable"]) could falsely intercept absolute shebangs if a registered runtime was using a relative executable name.

🛠️ The Fix

is_name_only Check: Introduced a check for path separators (/ or \) to properly distinguish between "bare names" (like py.exe or python3.14.exe) and explicit paths (C:\...\python.exe or ./python.exe).
NOTE: This is significantly safer than checking len(sh_cmd.parts) == 1, which breaks explicit normalized relative paths (like #!./python.exe) by stripping the ./ and incorrectly flagging them as bare names.
Gated Fallbacks: Virtual alias lookup, the is_default override, and the tag extraction wildcards are now safely gated behind is_name_only.
Absolute vs Relative Validation: Added a condition (not PurePath(i["executable"]).is_absolute()) to prevent absolute shebangs from falsely matching relative executable registries.

🧪 Impact

With these changes, absolute paths are safely bypassed in the virtual lookup traps, allowing them to cleanly fall through to the LookupError at the end of the block. This exception is caught gracefully by _parse_shebang, which delegates the absolute path to shutil.which() under _find_on_path().

This restores 100% interoperability with tools like uv and explicit local paths (./python.exe), without breaking any existing PEP 397/PEP 486 behaviors for standard bare names.

…bare name rules `PurePath.match()` performs right-aligned suffix matching, which caused absolute shebang paths (e.g., `C:\uv\python.exe`) to inadvertently evaluate true for bare names like `python.exe` or `python*.exe`. This resulted in two critical bugs: 1. Virtual environment paths were hijacked by the `is_default` trap, falling back to the global default Python runtime instead of the specified one. 2. Custom executables (like `python_uv_test.exe`) were intercepted by the fallback wildcard search, resulting in arbitrary slicing and lookup errors for phantom version tags (e.g., `_uv_test`). This commit introduces an `is_name_only` check (validating the absence of directory separators `/` and `\`) to safely distinguish bare commands from explicit paths. Gating the `is_default`, virtual alias, and wildcard extraction logic behind this check ensures explicit paths correctly fall through to `_find_on_path()`.

python-cla-bot · 2026-05-22T09:02:06Z

All commit authors signed the Contributor License Agreement.

zooba · 2026-05-22T10:06:06Z

Please file an issue first, and leave out the cheesy headings and just focus on the problem you're observing and the context it appears in.

zooba · 2026-05-22T10:07:04Z

Also, if an issue is "critical", please submit it as a security report using the Github Security Advisory feature. Otherwise, please refrain from assessing the severity of an issue - we can handle that, taking into account more than one single user.

mcexit · 2026-05-22T09:02:01Z

Description

This PR resolves a critical issue where scripts utilizing absolute or explicit relative shebangs (such as those generated by modern virtual environment managers like uv) are incorrectly intercepted, truncated, or routed to the wrong interpreter.

🐛 The Bugs

The original logic in _find_shebang_command heavily relied on pathlib.PurePath.match(). Because match() performs a loose right-aligned suffix match, PurePath("C:/uv/python.exe").match("python.exe") evaluates to True. This caused a chain reaction of unintended behaviors:

The is_default Trap: Absolute paths like C:\...\python.exe incorrectly triggered the is_default check, discarding the user's isolated environment and defaulting to the system-wide global Python.
The Wildcard Slicing Bug: The fallback check for python*.exe would intercept executables like C:\...\python_uv_test.exe and blindly slice the name ([6:-4]), causing the system to search for a phantom runtime tag (e.g., [ERROR] No runtime installed that matches _uv_test) and crash.
Relative Execution Trap:sh_cmd.match(i["executable"]) could falsely intercept absolute shebangs if a registered runtime was using a relative executable name.

🛠️ The Fix

is_name_only Check: Introduced a check for path separators (/ or \) to properly distinguish between "bare names" (like py.exe or python3.14.exe) and explicit paths (C:\...\python.exe or ./python.exe).
NOTE: This is significantly safer than checking len(sh_cmd.parts) == 1, which breaks explicit normalized relative paths (like #!./python.exe) by stripping the ./ and incorrectly flagging them as bare names.
Gated Fallbacks: Virtual alias lookup, the is_default override, and the tag extraction wildcards are now safely gated behind is_name_only.
Absolute vs Relative Validation: Added a condition (not PurePath(i["executable"]).is_absolute()) to prevent absolute shebangs from falsely matching relative executable registries.

🧪 Impact

With these changes, absolute paths are safely bypassed in the virtual lookup traps, allowing them to cleanly fall through to the LookupError at the end of the block. This exception is caught gracefully by _parse_shebang, which delegates the absolute path to shutil.which() under _find_on_path().

This restores 100% interoperability with tools like uv and explicit local paths (./python.exe), without breaking any existing PEP 397/PEP 486 behaviors for standard bare names.

…bare name rules `PurePath.match()` performs right-aligned suffix matching, which caused absolute shebang paths (e.g., `C:\uv\python.exe`) to inadvertently evaluate true for bare names like `python.exe` or `python*.exe`. This resulted in two critical bugs: 1. Virtual environment paths were hijacked by the `is_default` trap, falling back to the global default Python runtime instead of the specified one. 2. Custom executables (like `python_uv_test.exe`) were intercepted by the fallback wildcard search, resulting in arbitrary slicing and lookup errors for phantom version tags (e.g., `_uv_test`). This commit introduces an `is_name_only` check (validating the absence of directory separators `/` and `\`) to safely distinguish bare commands from explicit paths. Gating the `is_default`, virtual alias, and wildcard extraction logic behind this check ensures explicit paths correctly fall through to `_find_on_path()`.

python-cla-bot · 2026-05-22T09:02:06Z

All commit authors signed the Contributor License Agreement.

zooba · 2026-05-22T10:06:06Z

Please file an issue first, and leave out the cheesy headings and just focus on the problem you're observing and the context it appears in.

zooba · 2026-05-22T10:07:04Z

Also, if an issue is "critical", please submit it as a security report using the Github Security Advisory feature. Otherwise, please refrain from assessing the severity of an issue - we can handle that, taking into account more than one single user.

mcexit · 2026-05-22T09:02:01Z

Description

This PR resolves a critical issue where scripts utilizing absolute or explicit relative shebangs (such as those generated by modern virtual environment managers like uv) are incorrectly intercepted, truncated, or routed to the wrong interpreter.

🐛 The Bugs

The original logic in _find_shebang_command heavily relied on pathlib.PurePath.match(). Because match() performs a loose right-aligned suffix match, PurePath("C:/uv/python.exe").match("python.exe") evaluates to True. This caused a chain reaction of unintended behaviors:

The is_default Trap: Absolute paths like C:\...\python.exe incorrectly triggered the is_default check, discarding the user's isolated environment and defaulting to the system-wide global Python.
The Wildcard Slicing Bug: The fallback check for python*.exe would intercept executables like C:\...\python_uv_test.exe and blindly slice the name ([6:-4]), causing the system to search for a phantom runtime tag (e.g., [ERROR] No runtime installed that matches _uv_test) and crash.
Relative Execution Trap:sh_cmd.match(i["executable"]) could falsely intercept absolute shebangs if a registered runtime was using a relative executable name.

🛠️ The Fix

is_name_only Check: Introduced a check for path separators (/ or \) to properly distinguish between "bare names" (like py.exe or python3.14.exe) and explicit paths (C:\...\python.exe or ./python.exe).
NOTE: This is significantly safer than checking len(sh_cmd.parts) == 1, which breaks explicit normalized relative paths (like #!./python.exe) by stripping the ./ and incorrectly flagging them as bare names.
Gated Fallbacks: Virtual alias lookup, the is_default override, and the tag extraction wildcards are now safely gated behind is_name_only.
Absolute vs Relative Validation: Added a condition (not PurePath(i["executable"]).is_absolute()) to prevent absolute shebangs from falsely matching relative executable registries.

🧪 Impact

With these changes, absolute paths are safely bypassed in the virtual lookup traps, allowing them to cleanly fall through to the LookupError at the end of the block. This exception is caught gracefully by _parse_shebang, which delegates the absolute path to shutil.which() under _find_on_path().

This restores 100% interoperability with tools like uv and explicit local paths (./python.exe), without breaking any existing PEP 397/PEP 486 behaviors for standard bare names.

…bare name rules `PurePath.match()` performs right-aligned suffix matching, which caused absolute shebang paths (e.g., `C:\uv\python.exe`) to inadvertently evaluate true for bare names like `python.exe` or `python*.exe`. This resulted in two critical bugs: 1. Virtual environment paths were hijacked by the `is_default` trap, falling back to the global default Python runtime instead of the specified one. 2. Custom executables (like `python_uv_test.exe`) were intercepted by the fallback wildcard search, resulting in arbitrary slicing and lookup errors for phantom version tags (e.g., `_uv_test`). This commit introduces an `is_name_only` check (validating the absence of directory separators `/` and `\`) to safely distinguish bare commands from explicit paths. Gating the `is_default`, virtual alias, and wildcard extraction logic behind this check ensures explicit paths correctly fall through to `_find_on_path()`.

python-cla-bot · 2026-05-22T09:02:06Z

All commit authors signed the Contributor License Agreement.

zooba · 2026-05-22T10:06:06Z

Please file an issue first, and leave out the cheesy headings and just focus on the problem you're observing and the context it appears in.

zooba · 2026-05-22T10:07:04Z

Also, if an issue is "critical", please submit it as a security report using the Github Security Advisory feature. Otherwise, please refrain from assessing the severity of an issue - we can handle that, taking into account more than one single user.

mcexit · 2026-05-22T09:02:01Z

Description

This PR resolves a critical issue where scripts utilizing absolute or explicit relative shebangs (such as those generated by modern virtual environment managers like uv) are incorrectly intercepted, truncated, or routed to the wrong interpreter.

🐛 The Bugs

The original logic in _find_shebang_command heavily relied on pathlib.PurePath.match(). Because match() performs a loose right-aligned suffix match, PurePath("C:/uv/python.exe").match("python.exe") evaluates to True. This caused a chain reaction of unintended behaviors:

The is_default Trap: Absolute paths like C:\...\python.exe incorrectly triggered the is_default check, discarding the user's isolated environment and defaulting to the system-wide global Python.
The Wildcard Slicing Bug: The fallback check for python*.exe would intercept executables like C:\...\python_uv_test.exe and blindly slice the name ([6:-4]), causing the system to search for a phantom runtime tag (e.g., [ERROR] No runtime installed that matches _uv_test) and crash.
Relative Execution Trap:sh_cmd.match(i["executable"]) could falsely intercept absolute shebangs if a registered runtime was using a relative executable name.

🛠️ The Fix

is_name_only Check: Introduced a check for path separators (/ or \) to properly distinguish between "bare names" (like py.exe or python3.14.exe) and explicit paths (C:\...\python.exe or ./python.exe).
NOTE: This is significantly safer than checking len(sh_cmd.parts) == 1, which breaks explicit normalized relative paths (like #!./python.exe) by stripping the ./ and incorrectly flagging them as bare names.
Gated Fallbacks: Virtual alias lookup, the is_default override, and the tag extraction wildcards are now safely gated behind is_name_only.
Absolute vs Relative Validation: Added a condition (not PurePath(i["executable"]).is_absolute()) to prevent absolute shebangs from falsely matching relative executable registries.

🧪 Impact

With these changes, absolute paths are safely bypassed in the virtual lookup traps, allowing them to cleanly fall through to the LookupError at the end of the block. This exception is caught gracefully by _parse_shebang, which delegates the absolute path to shutil.which() under _find_on_path().

This restores 100% interoperability with tools like uv and explicit local paths (./python.exe), without breaking any existing PEP 397/PEP 486 behaviors for standard bare names.

…bare name rules `PurePath.match()` performs right-aligned suffix matching, which caused absolute shebang paths (e.g., `C:\uv\python.exe`) to inadvertently evaluate true for bare names like `python.exe` or `python*.exe`. This resulted in two critical bugs: 1. Virtual environment paths were hijacked by the `is_default` trap, falling back to the global default Python runtime instead of the specified one. 2. Custom executables (like `python_uv_test.exe`) were intercepted by the fallback wildcard search, resulting in arbitrary slicing and lookup errors for phantom version tags (e.g., `_uv_test`). This commit introduces an `is_name_only` check (validating the absence of directory separators `/` and `\`) to safely distinguish bare commands from explicit paths. Gating the `is_default`, virtual alias, and wildcard extraction logic behind this check ensures explicit paths correctly fall through to `_find_on_path()`.

python-cla-bot · 2026-05-22T09:02:06Z

All commit authors signed the Contributor License Agreement.

zooba · 2026-05-22T10:06:06Z

Please file an issue first, and leave out the cheesy headings and just focus on the problem you're observing and the context it appears in.

zooba · 2026-05-22T10:07:04Z

Also, if an issue is "critical", please submit it as a security report using the Github Security Advisory feature. Otherwise, please refrain from assessing the severity of an issue - we can handle that, taking into account more than one single user.

zooba closed this May 22, 2026

This was referenced May 24, 2026
PurePath.match() incorrectly intercepts and breaks absolute shebangs #348
Closed
Fix PurePath.match intercepting absolute shebang paths #349
Closed

zooba closed this May 22, 2026

This was referenced May 24, 2026
PurePath.match() incorrectly intercepts and breaks absolute shebangs #348
Closed
Fix PurePath.match intercepting absolute shebang paths #349
Closed

zooba closed this May 22, 2026

This was referenced May 24, 2026
PurePath.match() incorrectly intercepts and breaks absolute shebangs #348
Closed
Fix PurePath.match intercepting absolute shebang paths #349
Closed

zooba closed this May 22, 2026

This was referenced May 24, 2026
PurePath.match() incorrectly intercepts and breaks absolute shebangs #348
Closed
Fix PurePath.match intercepting absolute shebang paths #349
Closed

zooba closed this May 22, 2026

This was referenced May 24, 2026
PurePath.match() incorrectly intercepts and breaks absolute shebangs #348
Closed
Fix PurePath.match intercepting absolute shebang paths #349
Closed

zooba closed this May 22, 2026

This was referenced May 24, 2026
PurePath.match() incorrectly intercepts and breaks absolute shebangs #348
Closed
Fix PurePath.match intercepting absolute shebang paths #349
Closed

zooba closed this May 22, 2026

This was referenced May 24, 2026
PurePath.match() incorrectly intercepts and breaks absolute shebangs #348
Closed
Fix PurePath.match intercepting absolute shebang paths #349
Closed

zooba closed this May 22, 2026

This was referenced May 24, 2026
PurePath.match() incorrectly intercepts and breaks absolute shebangs #348
Closed
Fix PurePath.match intercepting absolute shebang paths #349
Closed

Uh oh!

Conversation

mcexit commented May 22, 2026

Description

🐛 The Bugs

🛠️ The Fix

🧪 Impact

Uh oh!

python-cla-botBot commented May 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zooba commented May 22, 2026

Uh oh!

zooba commented May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

mcexit commented May 22, 2026

Description

🐛 The Bugs

🛠️ The Fix

🧪 Impact

Uh oh!

python-cla-botBot commented May 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zooba commented May 22, 2026

Uh oh!

zooba commented May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

mcexit commented May 22, 2026

Description

🐛 The Bugs

🛠️ The Fix

🧪 Impact

Uh oh!

python-cla-botBot commented May 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zooba commented May 22, 2026

Uh oh!

zooba commented May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

mcexit commented May 22, 2026

Description

🐛 The Bugs

🛠️ The Fix

🧪 Impact

Uh oh!

python-cla-botBot commented May 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

python-cla-botBot commented May 22, 2026•
edited
Loading

python-cla-botBot commented May 22, 2026•
edited
Loading

python-cla-botBot commented May 22, 2026•
edited
Loading

python-cla-botBot commented May 22, 2026•
edited
Loading

python-cla-botBot commented May 22, 2026•
edited
Loading