Won't launch about tmux-fzf HOT 18 CLOSED

Okay, so here's what I've got so far:

The mentioned error occurs when ITEM is empty at main.sh:18. This can basically only happen if something is going wrong in .fzf-tmux. My first guess was that the embedded script might be outdated (and it is) but that's not the issue.

In my case, the issue is that tmux could not find fzf (more on that below). This results in the fallback at .fzf-tmux:10 which sets fzf="$(dirname "$0")/fzf. This fallback makes perfectly sense for the original script along with the compiled binary which is stored at this exact location. Obviously though, the fzf binary is not present in this folder (since it's not part of this repo), so the next line fails with fzf executable not found. This error however is printed to stderr, so it's not only not propagated up to the calling command substitution but also eaten up by tmux (i.e. tmux doesn't print stderr, e.g. tmux run-shell 'echo foo >&2' has no output). This made the error very difficult to spot.

So why is fzf not found? To begin with, I'm currently running zsh as my default shell and configured zplugin to manage lots of scripts, tools and helpers, one of which is fzf. Zplugin is very careful to not pollute global directories, so it stores all binaries in user-local paths and only propagates them to the current shell. The problem is that tmux somehow still uses bash instead of zsh, so zplugin is not loaded and therefore fzf is not in $PATH. The only thing I still don't get is why (any hints on this are appreciated). I've set the corresponding options (at least the ones I know of) but it doesn't work:

~ $ tmux show-options -g | grep default-
default-command "/usr/bin/zsh"
default-shell "/usr/bin/zsh"
~ $ tmux run 'echo $SHELL'
/bin/bash

So technically, it's not an issue with tmux-fzf, but all of the above is very specific to my case. For others it might be best to start checking whether tmux is able to find fzf: tmux run-shell 'command -v fzf'

from tmux-fzf.

I finally got it to work on all my setups. In the end I it was not the wrong shell being executed but rather a combination of zplugin's turbo mode (which delays plugin loading and executes it in the background to improve shell startup time) and the autostart setting of the tmux zsh plugin (which automatically starts a tmux session or attaches to an existing one on plugin load). So basically tmux was started automatically before the zplugin background process was able to load fzf into the PATH. I currently fixed it by simply disabling the turbo mode for fzf again.

To me, this issue is fixed now (as it never actually was an issue with tmux-fzf), but I'm happy to help out anyone else who is still having issues.

from tmux-fzf.

Please checkout #1 branch to see if it solves this problem.

from tmux-fzf.

Yeah, its launching as expected now.

from tmux-fzf.

Many thanks for fixing this.

from tmux-fzf.

I've merged #1 to master, now you can checkout master branch and update this plugin.

from tmux-fzf.

Hey @sainnhe, I'm running into the same issue. I'm on the latest version of the plugin.

Tmux Version: 2.3
OS: Debian 10

from tmux-fzf.

@leveled Very sorry, I've tried tmux 2.3 on my surfacepro/archlinux, but still cannot reproduce.

Please try minimal tmux configuration(with installation command only), and reinstall this plugin.

Btw, I think this may be related to the version of bash. What's your bash version?

from tmux-fzf.

I can confirm the issue on at least three setups. All of them run on the same .tmux.conf with minimal requirements (tpm + tmux-fzf). Moreover I should note that I use the tmux zsh plugin (including autostart).

1. Raspbian GNU/Linux 9 (stretch), 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux
   • zsh 5.3.1 (arm-unknown-linux-gnueabihf)
   • GNU bash, version 4.4.12(1)-release (arm-unknown-linux-gnueabihf)
   • tmux 2.3
2. WSL, Debian GNU/Linux 9 (stretch), 4.4.0-17134-Microsoft #706-Microsoft Mon Apr 01 18:13:00 PST 2019 x86_64 GNU/Linux
   • zsh 5.3.1 (x86_64-debian-linux-gnu)
   • GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
   • tmux 2.8
3. Linux Mint 19.2, 4.15.0-65-generic, #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
   • zsh 5.4.2 (x86_64-ubuntu-linux-gnu)
   • GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
   • tmux 2.6

I don't see any common denominator here, but if I find the time, I'll start some debugging.

from tmux-fzf.

It seems that some people still have this problem, but I'm unable to reproduce this on my Arch Linux on PC and Debian Server(debian 9.11 stretch). I have no idea what is going on.

Help wanted.

from tmux-fzf.

@Gerrit-K Very helpful. Thanks! I've updated README.

from tmux-fzf.

I'm running into this same issue

/Users/username/.tmux/plugins/tmux-fzf/scripts/.sh' returned 127

Tmux version 3.0a on OSX in ZSH.

tmux run-shell 'command -v fzf' returns /usr/local/bin/fzf

Is this plugin not working with Tmux 3?

Thanks!

from tmux-fzf.

@optijon Did you install gnu-sed on mac OS? #5

from tmux-fzf.

I did.

sed --version
=> sed (GNU sed) 4.8

from tmux-fzf.

@optijon Oh, I just noticed that you are using zsh right? Did you install GNU bash? It's listed in Requirements.

If you've installed bash, but still encounter this problem, you may need to debug this plugin by yourself because I can't reproduce this.

1. First of all, check if /path/to/tmux-fzf/scripts/.fzf-tmux works. You can test it using this command: ls | /path/to/tmux-fzf/scripts/.fzf-tmux
2. If it works, then debug /path/to/tmux-fzf/main.sh. To debug a specific line, you can simply comment out other lines and execute this script.

from tmux-fzf.

All of the required dependecies have been installed. I did some debugging and I was able to get this script to work. I'm very confused as to why it's working and my bash script-foo is not the greatest so maybe you can do something with this?

On line 113 in .fzf-mux if I add any arbitrary command in quotes above the FZF call like so:

if [[ -z "$TMUX" || "$opt" =~ ^-h && "$columns" -le 40 || ! "$opt" =~ ^-h && "$lines" -le 15 ]]; then
  "${wait 10}"
  "$fzf" "${args[@]}"
  exit $?
fi

And it works.

If you remove the line, $? shows a 2 status. Could this be some sort of timing issue? Maybe something to do with the while loop above?

from tmux-fzf.

@optijon The scripts/.fzf-tmux is a modified version of the original fzf-tmux in the official repository. I use a modified one because the original one doesn't work before, but the it seems to work now(I don't know why, but it works).

So I created a branch named original-fzf-script which uses the original fzf-tmux, could you checkout this branch and get it a try?

Also, if the problem is caused by fzf-tmux script, you can try the fzf-tmux command in your shell directly, like this:

ls -a ~ | fzf-tmux

This command is provided by fzf, see here for detailed guide.

Sorry but I can't provide more help, because this script is not written by me, it's copied from the official repository. If this issue can be reproduced using the original one, maybe you can consider to open an issue in junegunn/fzf.

from tmux-fzf.

I finally got it to work on all my setups. In the end I it was not the wrong shell being executed but rather a combination of zplugin's turbo mode (which delays plugin loading and executes it in the background to improve shell startup time) and the autostart setting of the tmux zsh plugin (which automatically starts a tmux session or attaches to an existing one on plugin load). So basically tmux was started automatically before the zplugin background process was able to load fzf into the PATH. I currently fixed it by simply disabling the turbo mode for fzf again.

To me, this issue is fixed now (as it never actually was an issue with tmux-fzf), but I'm happy to help out anyone else who is still having issues.

Life saver 😄

from tmux-fzf.