Summary

Problem Description

When the executable directory isn't in the PATH, uv tool update-shell attempts to use environment variables to determine the shell. If it succeeds in determining the shell, it will use that to fix the issue with the PATH. However, if the environment variables it checks for are unavailable, the command fails with error: The executable directory /home/user/.local/bin is not in PATH, but the current shell could not be determined.

While it's typical for these environment variables to be set, there are scenarios where they may not be. For example, the Linux x64 release of the self-hosted GitHub Actions runner application uses bash to call commands, but it does not export BASH_VERSION or SHELL as environment variables. Thus, if the executable directory is not already in the PATH, uv tool update-shell will raise the error mentioned above.

For unix-like systems at least, when the environment variables are not informative, it would be nice for uv tool update-shell to check the parent process command as a fallback approach. I'd like to introduce a Pull Request for this behavior.

Environment Information

• uv version: 0.8.11
• Operating system: Ubuntu 22.04.5 LTS
• Shell: zsh 5.8.1 (x86_64-ubuntu-linux-gnu)

Minimal Reproduction

# Remove shell environment variables and run uv tool update-shell
env -u ZSH_VERSION -u SHELL -u PATH $(which uv) tool update-shell --verbose

DEBUG uv 0.8.11
DEBUG Ensuring that the executable directory is in PATH: /home/user/.local/bin
error: The executable directory /home/user/.local/bin is not in PATH, but the current shell could not be determined

While this is expected behavior, the calling process could be used to inform the uv of what shell is in use. See, for example:

env -u ZSH_VERSION -u SHELL -u PATH $(which ps) -p $$ -o comm=

zsh

Proposed Solution

Add a fallback mechanism to Shell::from_env() for unix-like systems that inspects the parent process when environment variables are unavailable. The implementation would:

1. Get the parent process ID
2. Read /proc/<ppid>/exe to determine the parent executable path
3. Fall back to /proc/<ppid>/comm if the exe symlink fails
4. Use the existing parse_shell_from_path() function to identify the shell type

This approach should be fully compatible with existing workflows. It would only have an impact in cases where, currently, an error is raised.

Example

No response