Search Directory File Preview Says Existing File Doesn't Exist

[Phantom1472]

Hello,

When using CTRL+ALT+F to search a directory, when my pwd is /home/{user}/Downloads, it works great and all file and directory previews work as expected (even using exa after I configured it) and everything is displayed corretly.

But if I cd .. to /home/{user} and run CTRL+ALT+F, now the directory/file preview is saying "{dir/file} doesn't exist" for every directory/file I try to preview. Even directories/files from /home/{user}/Downloads that were displayed correctly from within /home/{user}/Downloads.

Did I do somthing wrong? Is this a known issue? How can I fix it?

My OS is: Ubuntu 21.10

All software dependency versions are:

fish -v         
fish, version 3.3.1

fzf --version                  
0.29.0 (dc975e8)

fd -V           
fd 8.2.1

bat --version
bat 0.19.0 (59a8f58)

[PatrickF1]

Hi, this might be a bug. what's your username? Does it have a space in it?

[PatrickF1]

just run echo $fzf_preview_dir_cmd etc.

[Phantom1472]

Ok, i looked and i have none of these env vars defined... So i guess that's not it.

[PatrickF1]

Welp sorry! I have no idea what it is then. I have done as much as I can from my side without remotely controlling your computer. If I could--and you can do this if you really want to fix this bug--is to add breakpoints to the function _fzf_search_directory and inspecting the variables to find where the problem originates. But I'm not going to make you go through that.

[Phantom1472]

I'd love to do that! How do you put a break point in that function?

[PatrickF1]

breakpoint see https://fishshell.com/docs/current/language.html#debugging-fish-scripts.
That or just echo the variables the old fashioned way.

[interestingLSY]

I have some clue... I inserted echo (pwd) into _fzf_preview_file.fish and found out that the current working directory is always /home/{USER} instead of (the real) working directory.

[interestingLSY]

More: Just before _fzf_wrapper calls fzf, the CWD (current working directory, can be obtained by executing pwd) is correct. But when fzf calls _fzf_preview_file, the CWD always points to the home directory of the user.

[interestingLSY]

When I execute fzf --preview="pwd" under both bash and fish shell, the output is always the home directory of the current user.

Seems that this issue is related to fzf?

[interestingLSY]

My temporary dirty hack is to replace --preview='_fzf_preview_file {}' with --preview="_fzf_preview_file $(pwd)/{}" in --preview='_fzf_preview_file {}'. It works.

My environment:

OS: Ubuntu 22.04
fish, version 3.6.1
fd 8.3.1
fzf 0.29 (devel)
bat 0.19.0

[Phantom1472]

More: Just before _fzf_wrapper calls fzf, the CWD (current working directory, can be obtained by executing pwd) is correct. But when fzf calls _fzf_preview_file, the CWD always points to the home directory of the user.

That sounds exactly like something that would cause that problem...

@PatrickF1 can you take a look at this and tell me if you can find the bug with this new info?

[PatrickF1]

Thanks @interestingLSY for debugging. Yup, I may need to change the preview function to --preview="_fzf_preview_file $(pwd)/{}". Out of curiosity, are y'all cd'ing in your config.fish? Cause by default, I think starting a new fish shell reuses your current directory.

[Phantom1472]

Thanks @interestingLSY for debugging. Yup, I may need to change the preview function to --preview="_fzf_preview_file $(pwd)/{}". Out of curiosity, are y'all cd'ing in your config.fish? Cause by default, I think starting a new fish shell reuses your current directory.

I did not add any cd'ing in the config.fish, there may have been some added by other addons, i couldn't tell you because the Linux machine i had when i opened this issue is no longer with me, so i don't have much to add to the conversation unfortunately, hope you fix the issue anyway!

[PatrickF1]

Btw, I realized changing it to --preview="_fzf_preview_file $(pwd)/{}" is a bad option because it'll make the list of results in fzf much longer, unnecessarily. So instead of file.txt, it'll be /Users/user/dir/file.txt. That's bad aesthetics and not worth it for this super rare bug, if it's even a bug. I suspect when this happens something in the config is changing directories or overriding $PWD because the default behavior of all shells seems to be to inherit $PWD. If someone insists on changing directories inside their config, they're gonna have to use @interestingLSY 's hack.