Skip to content

Fix new_os_window_with_cwd in presence of defunct processes#9441

Merged
kovidgoyal merged 1 commit intokovidgoyal:masterfrom
keysmashes:push-nyomnyoroxxm
Jan 31, 2026
Merged

Fix new_os_window_with_cwd in presence of defunct processes#9441
kovidgoyal merged 1 commit intokovidgoyal:masterfrom
keysmashes:push-nyomnyoroxxm

Conversation

@keysmashes
Copy link
Copy Markdown
Contributor

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_cwd will 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 less invokes 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, and new_os_window_with_cwd starts 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 strict parameter was added to os.path.realpath in 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 with abspath_of_exe, but for consistency's sake I changed the realpath invocation there in the same way, since the only callsite has a with 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:

  1. Have lesspipe or similar installed (export LESSOPEN="|lesspipe.sh %s")
  2. cd to some directory other than your home directory/the directory kitty opens in
  3. Use less to open a file which lesspipe will process, e.g. a tar file
  4. Scroll to the end of the file (G)
  5. Invoke new_os_window_with_cwd and observe that you end up in your home directory, not the current directory

@kovidgoyal kovidgoyal merged commit d9071cd into kovidgoyal:master Jan 31, 2026
14 checks passed
@keysmashes keysmashes deleted the push-nyomnyoroxxm branch January 31, 2026 10:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants