FZF_DEFAULT_COMMAND propagated to execute() and execute-silent() programs

[genotrance]

• Category
  • [x] fzf binary
  • [ ] fzf-tmux script
  • [ ] Key bindings
  • [ ] Completion
  • [ ] Vim
  • [ ] Neovim
  • [ ] Etc.
• OS
  • [ ] Linux
  • [ ] Mac OS X
  • [ ] Windows
  • [ ] Windows Subsystem for Linux
  • [ ] Etc.
• Shell
  • [ ] bash
  • [ ] zsh
  • [ ] fish

When you use FZF_DEFAULT_COMMAND along with execute() or execute-silent(), that value is propagated to the child program.

For example, when using ff to open a cmd.exe window in a directory selected in fzf, it all works fine. But now if you now run fzf in that cmd.exe or run fzf inside Vim started in that cmd.exe, it only finds directories since FZF_DEFAULT_COMMAND was set to "dir /s/b/ad" by ff before calling fzf.

Fix is to unset FZF_DEFAULT_COMMAND before executing any child programs or removing it from the ENV of the child before execCommand().

[genotrance]

It seems having fzf unset FZF_DEFAULT_COMMAND breaks the assumption that it could be a default value set globally. There's no way to know whether it was set just for this run or should be retained for future invocations.

It might be better to offer a command line option to pass this info to fzf for this scenario. Changing this from a defect to a feature request for a command line option.

[junegunn]

When you use FZF_DEFAULT_COMMAND along with execute() or execute-silent(), that value is propagated to the child program.

This is natural.

I don't see why you would want to redefine FZF_DEFAULT_COMMAND on child processes when you can simply redirect the output of some command to the standard input of fzf?

foo | fzf

[genotrance]

ff already does that today and runs fzf on the same tty as itself so if data is directed to ff using a pipe, it is automatically picked up by fzf and displayed.

However, if you want to use one of ff pre-defined actions which defines a specific command to populate fzf, the only way to do it is via FZF_DEFAULT_COMMAND. That's why I'm requesting a command-line way.

No doubt fzf works great the way it is but this is a use case specific to ff and how it leverages fzf for what it does best.

[vovcacik]

Possible workaround: execute(start /i cmd /c fzf).