fzf sometimes makes stderr useless in the calling shell

[fd0]

Hi,

first of all: thank you very much for all your work, I love fzf and use it for shell history search!

• I have read through the manual page (man fzf)
• I have the latest version of fzf
• I have searched through the existing issues

Info

• OS
  • Linux
• Shell
  • zsh

Problem / Steps to reproduce

I'm using fzf for history searching within zsh. Unfortunately, something (maybe fzf?) somehow manages to make stderr useless in the calling process (the shell), so that afterwards neither fzf nor any process printing stuff to stderr work any more.

It happens frequently for me, but I'm unable to reproduce it reliably. The only option is to close the shell, which is very annoying.

When it happens, the shell behaves as follows:

• fzf when run (manually or via shortcut (^R)) does not print anything
• Programs cannot print error messages (so echo foo >&2 prints nothing)
• FD 2 of the shell itself is mapped to /dev/null:

$ ls -al /proc/$$/fd
total 0
dr-x------ 2 fd0 users  0 Mai  2 11:22 .
dr-xr-xr-x 9 fd0 users  0 Mai  2 11:22 ..
lrwx------ 1 fd0 users 64 Mai  2 11:22 0 -> /dev/pts/2
lrwx------ 1 fd0 users 64 Mai  2 11:22 1 -> /dev/pts/2
lrwx------ 1 fd0 users 64 Mai  2 11:22 10 -> /dev/dri/renderD128
lrwx------ 1 fd0 users 64 Mai  2 11:22 11 -> /dev/pts/2
lrwx------ 1 fd0 users 64 Mai  2 11:22 12 -> /dev/ptmx
l-wx------ 1 fd0 users 64 Mai  2 11:22 2 -> /dev/null

I'd like to get to the bottom of this bug (it is very annoying for me), so please let me know if there's anything I can try or if there's any way to help out!

Thanks!

[junegunn]

I've never experienced the problem. What's your zsh --version? Have you tried upgrading zsh?

[fd0]

It happens with zsh 5.7.1 on Debian as well as zsh 5.8 on Arch, using alacritty, tilix and rxvt-unicode as terminal emulators. I'm using the same theme (sorin). It asynchronously updates the right-hand prompt with the current git status.

Now that I think about it, I can only remember cases where the issue occurs when I'm working on code, i.e. I'm within a git repository checkout. May that have something to do with it?

Do you maybe know how we can get into a situation where the calling shell has stderr linked to /dev/null? I can manually close the file descriptor for stderr, the shell (as well as fzf) behaves the same, but the file 2 vanished from /proc/$$/fd:

% ls -al /proc/$$/fd
total 0
dr-x------ 2 alex alex  0 Mai  4 10:10 .
dr-xr-xr-x 9 alex alex  0 Mai  4 10:10 ..
lrwx------ 1 alex alex 64 Mai  4 10:10 0 -> /dev/pts/2
lrwx------ 1 alex alex 64 Mai  4 10:10 1 -> /dev/pts/2
lrwx------ 1 alex alex 64 Mai  4 10:10 2 -> /dev/pts/2
[...]

% exec 2>&-

% ls -al /proc/$$/fd
total 0
dr-x------ 2 alex alex  0 Mai  4 10:10 .
dr-xr-xr-x 9 alex alex  0 Mai  4 10:10 ..
lrwx------ 1 alex alex 64 Mai  4 10:10 0 -> /dev/pts/2
lrwx------ 1 alex alex 64 Mai  4 10:10 1 -> /dev/pts/2
[... no fd 2 ...]

Does fzf do anything with the file descriptors inherited from the shell? Or is maybe the async prompt update an issue?

I'm grateful for any hints! Thank you very much! :)

[fd0]

Oh wow, I'm terribly sorry! I just found a very similar bug report (mafredri/zsh-async#35) for the zsh-async module which is used by the git status update, so it's unlikely to be related to fzf. I'm closing this for now, thanks!