Fix new_os_window_with_cwd in presence of defunct processes#9441
Merged
kovidgoyal merged 1 commit intokovidgoyal:masterfrom Jan 31, 2026
Merged
Fix new_os_window_with_cwd in presence of defunct processes#9441kovidgoyal merged 1 commit intokovidgoyal:masterfrom
kovidgoyal merged 1 commit intokovidgoyal:masterfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a hilariously specific problem, but: right now, if you have a defunct process as some descendant of your shell and the PID of that process is the highest of any PID in your session, then
new_os_window_with_cwdwill fail to determine the current working directory and instead put you in~(or wherever you launched kitty from).For example, this happens for me when
lessinvokes a streaming input preprocessor ($LESSOPEN starts with|): once I have scrolled to the end of the file, the preprocessor process remains defunct until less exits, andnew_os_window_with_cwdstarts putting me in my home directory until I quit less.This is ultimately due to a behaviour change in Python 3.13 (python/cpython@7407267, a backport of python/cpython#118489), so it is not reproducible on 3.12 and previous versions. The
strictparameter was added toos.path.realpathin 3.10, which appears (looking at pyproject.toml) to be the earliest version kitty supports, so I think adding that is the best solution and should revert to the pre-3.13 behaviour: if the cwd of a process is unreadable, it's probably best to skip it and try a different process.Strictly speaking, I only tested the change on line 65 (the Linux version of
cwd_of_process) – I don't know if this situation is actually possible on macOS/FreeBSD, and I don't have machines available to check easily. I also don't know if the same problem could occur withabspath_of_exe, but for consistency's sake I changed therealpathinvocation there in the same way, since the only callsite has awith suppress(Exception)already so is presumably expecting an exception to be raised if the symlink is unreadable.Some repro steps for the bug this fixes:
export LESSOPEN="|lesspipe.sh %s")cdto some directory other than your home directory/the directory kitty opens innew_os_window_with_cwdand observe that you end up in your home directory, not the current directory