fzf randomly breaks on Ctrl-Z

[LunarLambda]

Checklist

• [x] I have read through the manual page (man fzf)
• [x] I have searched through the existing issues
• [x] For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version

0.65.2 (416aff86)

OS

• [x] Linux
• [ ] macOS
• [ ] Windows
• [ ] Etc.

Shell

• [x] bash
• [x] zsh
• [ ] fish

Problem / Steps to reproduce

https://asciinema.org/a/hYkNegDqGD8vq8rYzEXmnUtUd bash (no config) https://asciinema.org/a/n0ajyrADJIR01fcxN6XolMdX8 zsh (no config)

I was messing with a --preview command that potentially suspends fzf to take over the terminal and display a dialogue, then foregrounds fzf again. This works, except I can't find a way to force fzf to redraw after being continued. Then while testing fzf's redraw behaviour, I found that suspending fzf just doesn't work in general. Sometimes Ctrl-Z followed by fg works 1-4 times before breaking, but it's extremely inconsistent.

[junegunn]

Not sure why I can't reproduce the problem.

[LunarLambda]

I was mostly encountering this inside tmux, but also outside. Maybe it has something to do with TERM=tmux-direct/TERM=tmux-256color?. Otherwise, this is on Arch Linux, and like I said both bash and zsh were run with completely default settings.

[LunarLambda]

I can reproduce it in and outside of tmux, with various TERM settings (incl. xterm-256color), and in various terminal emulators (wezterm, ghostty, xterm)

But it's very inconsistent, so I almost suspect a weird race condition with signals and fzf's terminal handling.

fzf should most likely do a full terminal-reinitialization + redraw on SIGCONT, similar to what Neovim does.